Yes, it should show up as this. But only, if the Kernel (Or mk) can understand the way how partitions are written to disk. (Partition Tabke Format). I came in contact with this stuff, when I tried to use a RDB-Harddisk from an Amiga 68k in my P100 System. Linux recognized /dev/hdc but not /dev/hdc1,hdc2,hdc3.
Granted, but that doesn't have anything to do with the *names*. My point was that although ~100% of Linux machines follow the /dev/{s,d}d[a-h][1-16] scheme for hard drives, this isn't mandatory. I could name them anything I want, and as long as the device works in the first place, it will continue to work with the new name.
I made two stupid factual errors in the email that started this thread with respect to the naming conventions used by linux and mklinux, but all the same if fdisk knows how to name partitions, and hfsutils (or whatever) wants to have similar functionality to fdisk, I presume that it should have *some* knowledge of partitions (not necessarily of devices).
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.
Assuming that we *want* to do this, there are ways around the problem. linux (and mklinux) generally calls a raw devices something like /dev/sdb (my previous email was incorrect wrt. this), and this raw device has major device number 8 and minor device number 16.
If you were to run 'hdisk /dev/sdb' then hdisk could do one of two things:
1) assume that the partition numbers can be found by adding a digit to the end of the name, "because it's linux".
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 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).
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.
[ Nick ] __ Nick Stephen MkLinux: http://www.mklinux.apple.com OSF Research Institute Homepage: http://www.gr.osf.org/~stephen 2, Avenue de Vignate Email: stephen@gr.osf.org 38610 Gieres - France Phone: +33 76 63 48 72 Fax: +33 76 51 05 32
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() BSD bsd_disklabel_partition() OSF osf_partition() SUN sun_partition() Amiga amiga_partition()
Adding another one for Apple partitions is easy (apart from block size considerations on CD-ROMs).
- 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.
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.
For what it's worth, the following Perl code will read and display the partition map of an Apple-partitioned disk. For each HFS partition, it also displays the name of the volume contained therein. If this is useful, perhaps I will roll some form of it into the hfsutils distribution.
It has always been possible to select an alternate HFS partition for hfsutils by supplying the desired ordinal HFS partition number (if other than 1) to `hmount'. (Note that this only counts HFS partitions; other partitions are ignored by hfsutils when counting HFS partitions.)
At some point I would actually like to write a partitioning utility that writes an Apple partition map; is this what you're really looking for, Nick?
Robert Leslie rob@mars.org
#!/usr/bin/perl #
die "Usage: $0 device-path\n" unless (@ARGV == 1);
($disk) = @ARGV;
format STDOUT_TOP = # Partition Type HFS Volume Name Start Length -------------------------------------------------------------------------------
Well that was pretty useless. Let's try that again *thwap Majordomo* ...
-rob
#!/usr/bin/perl #
die "Usage: $0 device-path\n" unless (@ARGV == 1);
($disk) = @ARGV;
format STDOUT_TOP = # Partition Type HFS Volume Name Start Length ------------------------------------------------------------------------------- .
format STDOUT = @# @<<<<<<<<<<<<<<<<<<<<<<<<<<<< @<<<<<<<<<<<<<<<<<<<<<<<<<< @####### @######## $bnum, $pmParType, $drVN, $pmPyPartStart, $pmPartBlkCnt .
open(DISK, $disk) || die "$disk: $!\n";
$bnum = 1;
do { seek(DISK, 512 * $bnum, 0) || die "seek: $!\n"; read(DISK, $block, 512) || die "read: $!\n";
($pmSig, $pmMapBlkCnt, $pmPyPartStart, $pmPartBlkCnt, $pmParType) = (unpack('n2 N3 A32 A32 N10 A16', $block))[0, 2..4, 6];
die "$disk: unsupported partition map\n" if ($pmSig == 0x5453); die "$disk: no partition map\n" unless ($pmSig == 0x504d);
if ($pmParType eq 'Apple_HFS') { seek(DISK, 512 * ($pmPyPartStart + 2), 0) || die "seek: $!\n"; read(DISK, $block, 512) || die "read: $!\n";
($drVN) = (unpack('n N2 n5 N2 n N n c A27', $block))[14]; } else { $drVN = ''; }
write; } while ($bnum++ < $pmMapBlkCnt);
close(DISK);
__END__