new hfstools command : hdisk?
David E A Wilson
Thu, 1 Aug 1996 09:57:55 -1400 (EST)
> Then again, for many systems that run the hfstools, using native
> partition numbering is meaningless on a HFS disk since the O/S
> can't use the disk's partition table.
It is fairly simple to add this functionality to Linux. I have already done
this in an early attempt to read ProDOS formatted CD-ROMs.
In linux/drivers/block/genhd.c in v2.0.10 we find routines to handle the
following partition types:
MS-DOS msdos_partition(), extended_partition()
Adding another one for Apple partitions is easy (apart from block size
considerations on CD-ROMs).
> 2) assume that successive partition numbers can be found by looking
> for a device special file with the same major number and an incremented
> minor device number, and go look up the appropriate name.
This works fine for SCSI HDs and IDE CD-ROMs but not SCSI CD-ROMs as no
minor numbers are allocated for partitions on them.
> This second approach would solve the naming problem but a problem
> still remains if different operating systems "hide" HFS partitions (I
> believe that MacBSD transparently ignores non-unix partitions because
> of a hard limit to the number of partitions, correct me if I'm wrong).
Linux could run into similar problems as it only has 15 partition entries
per SCSI hard disk. IDE disks and CD-ROMs have 63.
> All in all I think I'm just confusing things, because hfstools are
> very useful as they are :) Maybe just a simple mechanism for
> displaying hfs partitions in an hfstools specific manner and hmounting
> a specific partition (rather than always the first partition) in an
> hfstools specific manner would be more appropriate.
Once the OS can recognise the partitions then mounting of individual HFS
partitions is no harder than any other type.
David Wilson Dept CompSci Uni Wollongong Australia email@example.com