--- On Fri, 3/8/12, Vyacheslav Dubeyko <slava@xxxxxxxxxxx> wrote: > Hi, > > On Fri, 2012-08-03 at 09:01 +0100, Hin-Tak Leung wrote: > > > I did not make those volumes - they were downloaded > them from Apple's developer web site (http://developer.apple.com/xcode/ - sorry, free > registration required). Some of them have additional > compression built-in - there are 3rd-party tools on linux > for decompressing them - but these 4 appear to be plain disk > images, of sorts (I have a small random selection, from > helping Mac-user friends to set up their dev environment > from time to time). > > > > Could you share dump of the first and secondary volume > headers from one > of these volumes, offset of secondary ones in bytes from > volume begin > and output any utilities with size of the partition? > > I think that from file system points of view all can be OK > (without > anomaly). But partition map can have some different value of > volume > size. I know parition map can have different ideas about volume sizes. I was talking about the HFS+ volume header itself - located on the 3rd 512-byte, and *supposedly* located on the 2nd 512-byte from the "end" - the "end" being the size declared by multiplying the blocksize with blockcount in the HFS+ header, and counting from 1024 byte before the primary header. The smaller set of files also have blockcount way over the image size itself, and the 2nd header is located at the beginning of the last used 4k block. Here they are: dd if=xcode_4.3.3_for_lion.dmg of=/tmp/header1 count=3 skip=65 dd if=xcode_4.3.3_for_lion.dmg of=/tmp/header2 count=1 skip=3858241 ("header1" includes the 2x512 bytes before the primary volume header, hence count=3). The HFS+ header says 482273 blocks of 4 KiB, which means the 2nd header sould be located at 65 + 482273 * 8 - 2, i.e. at skip 3858247 instead of 3858241 as above. > It is possible to talk about anomaly after real reproduction > of the > problem on real hardware, from my point of view. > > With the best regards, > Vyacheslav Dubeyko. > > > > cltools_lion_latemarch12.dmg > > command_line_tools_for_xcode.dmg > > xcode_4.3.1_for_lion.dmg > > xcode_4.3.3_for_lion.dmg > > > > These have an Apple partition map, an empty ATA driver > partition and and HFS+ partition. The HFS+ partition's > header says it uses block size 4k, and the 2nd volume header > is located at 4k from the end of the HFS+ partition rather > than 1024 byte from the end. The two command_line_tools* > also have an extra issue - its HFS+ header says it is about > 400MB in total, half of that free, but the actual size is > only 180MB and the secondary volume header is located on the > last 4k block (i.e. freespace is not included), and not 1024 > byte from the end. > > > > These are the "official" Apple development tool > distributions, and quite obviously millions of Apple-centric > developers are using them without problem. when they are > slightly off-spec, I think one should interpret this as > Apple extending/changing/adjusting the HFS+ format, > relaxing/changing some of the constraints in the case of > disk images. > > > > The "sizelimit" I wrote in the redhat bug report is > modified to fool the linux kernel into finding the 2nd > volume header in its "expected" place to loop-back mount > that image i.e. the true end of the HFS+ volume is 3072 > bytes further, from the HFS+ header. (the redhat bug report > is about sizelimit not working from mount -o, but need to be > specified separately on losetup). > > > > > On Fri, 2012-08-03 at 05:21 +0100, Hin-Tak Leung > wrote: > > > > I think I found another small bug in the > kernel's > > > hfsplus support, or more properly, a difference > between how > > > the linux kernel deal with HFS+ images versus how > Mac OS X > > > does it. > > > > > > > > Some of the necessary/boring details are in > the bug > > > report https://bugzilla.redhat.com/show_bug.cgi?id=845419 > > > (which isn't about this bug, but some other issues > about > > > mount options). > > > > > > > > According to Apple's TN1150 technote (the > HFS+ > > > specification), the primary volume header is at > 1024 bytes > > > into an image, while a duplicate back-up version > of it, the > > > secondary volume header, is at 1024 bytes counting > from the > > > end of the image/storage. (or for 512-sector > devices, the > > > 3rd sector from the beginning and the 2nd sector > from the > > > last). > > > > > > > > Apple's xcode images (I just happen to have > those in my > > > hard disc, as I am looking at any/every HFS+ disk > images I > > > might have), and all the apple tools images I > have, have an > > > anomaly: the secondary volume header is located > one logical > > > block (a logical block being 4k in this case from > the HFS+ > > > header) from the end. > > > > > > > > Indeed, apple's own fsck.hfsplus itself > complains about > > > the xcode image not of the right size, if you set > up the > > > loopback device as I wrote in the bug report. > OTOH, since > > > Apple developers all over the world download the > xcode > > > images and access them as virtual disk images on > their > > > computers on a daily basis, and Apple can change > what is > > > considered "correct behavior" about HFS+ without > notice, > > > this anomaly probably should be supported. > > > > > > > > The wording of TN1150 is also a bit ambiguous > about the > > > 2nd volume header - it says it is for disk repair > utilities > > > only, and may not be where it said it is. > > > > > > > > So I am wondering whether the linux kernel > should as it > > > currently does, enforce the 2nd volume header > being at 1024 > > > bytes from the end and agree with the primary > volume header, > > > and refuse to mount, as correct. It also seems > unnecessary > > > for read-only mounts, or image-loop-back mounts. I > have two > > > suggestions: > > > > > > > > - for read-only/look-back mounts, allows the > 2nd volume > > > header to not agree with the primary, with a > warning. > > > > > > > > - or, for read-only/look-back mounts, allows > the 2nd > > > volume header to locate one logical block from the > end > > > rather than 2 x 512-sectors from the end, if the > logical > > > block according to the HFS+ header is larger than > or > > > different from 512. > > > > > > > > > > > > > > > -- > > To unsubscribe from this list: send the line > "unsubscribe linux-fsdevel" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > >
Attachment:
header1
Description: Binary data
Attachment:
header2
Description: Binary data
