Hi Hin-Tak, It is very strange. My experience with HFS+ volumes is different. I worked with HFS+ volumes with different block sizes and different volumes' sizes but I haven't such anomaly. Maybe, I don't know about last changes or some specific use-cases. Could you share more details about your volumes (size in bytes, size in blocks, block size, offset in bytes of second volume header and so on)? What utilities did you use for HFS+ volumes creation? With the best regards, Vyacheslav Dubeyko. 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
