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. 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 -- 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
