GNOME Bugzilla – Bug 665221
Add support for fsck.hfs in hfsprogs
Last modified: 2020-11-13 10:41:16 UTC
Created attachment 202459 [details] [review] Patch to support fsck.hfs hfsck appears to have been replaced with fsck.hfs on my install. I'm not sure if this is a distro specific thing or not. I any case this patch adds support for fsck.hfs.
Which GNU/Linux distribution are you using? As far as I know, the HFS Utilities have not been updated since 1998. http://www.mars.org/home/rob/proj/hfs/ I believe that the command fsck.hfs is part of the newer hfsprogs package. The hfsprogs package provides support for both hfs and hfsplus (hfs+) file systems.
I have kubuntu 11.04 but this has been the case at least since 9.04. hfsutils is version 3.2.6-11build3. Yes the fsck.hfs is part of hfsprogs. For some reason hfsck isn't included in hfutils. The main idea I had with the patch was to allow hfs checking to work in gparted with either tool since they seem to offer the same functionality.
Created attachment 203506 [details] GParted details log with failed hfs file system check Thank you Michael for the explanation, and also for the original patch. I applied this patch and recompiled GParted. To test, I used the following steps in Kubuntu 11.04: 1) Create a new hfs partition (2 GiB) with GParted and apply this operation. 2) Select this new hfs partition 3) Choose the menu option "Partition --> Check". 4) Apply this check operation When I perform the above steps, the fsck.hfs step always fails. Would you be able to test and provide your results?
I am getting the same results here. Interestingly disk utility in OS X reports the same error checking such a partition.
That error is legitimate. HFS Utilities does not correctly compute the minimum block size. For a 1 GB HFS Utilities computes 65534 8Kb blocks. According to HFS specs 65534 * 8 = 524,272Kb or about .5 GB of allocation space. This is not a valid HFS volume by Apple's specs. fsck.hfs and other programs in hfsprogs use the same code apple uses in computing the allocation block size. For a 1GB drive this should be 16KB. I wouldn't trust HFS Utilities for any partition larger than 64Mb the maximum the can be represented by a 512 byte allocation block.
Thanks Michael for confirming this problem. Would you be able to point me to a specification that indicates the maximum supported size for HFS? GParted has the ability to limit the maximum size for each type of partition. Currently this is set as follows in the include/hfs.cc file: fs .MAX = 2048 * MEBIBYTE ; Where a MEBIBYTE is 1024 * 1024.
The relivant specs are at: http://developer.apple.com/legacy/mac/library/documentation/mac/Files/Files-102.html#HEADING102-0. The maximum theoretically support size is (65,535*4,294,966,784)/(1024*1024)=268,431,328 MB or about 260 TBs. However, this would result in a 4 GB allocation block size. Apple caps the size at 1Gb when formatting through disk utility. The code being used by fsck.hfs does not enforce this limit. It only checks to see if the block size is bellow the minimum needed to represent the entire volume. Wikipedia claims a 2Tb upper limit for volume size but I don't know how they got that number. HFS Utilities does not compute block size correctly for anything 64MBs or up. I did not test smaller partitions. As result it is writing an invalid MDB. mkfs.hfs should be able to handle this properly but I haven't tested it yet.
After some testing, the fsck.hfs command appears to not have very much use. At least in it's current state of affairs. I tested with the following hfs partition sizes (2 GiB, 1 GiB, 512 MiB, 256 MiB, 128 MiB, 64 MiB, 32 MiB), and fsck.hfs failed on every one of these newly created partitions. The output was similar in all cases: $ sudo fsck.hfs -f -y /dev/sda6 ** /dev/sda6 ** Checking HFS volume. Invalid allocation block size (4294967295, 262142) ** Volume check failed. $ It was only when I tried running fsck.hfs on a 16 MiB partition that the command actually succeeded. $ sudo fsck.hfs -f -y /dev/sda9 ** /dev/sda9 ** Checking HFS volume. $ Based on this testing, I think it best not to add the fsck.hfs command to GParted for hfs file systems. If it is added, then GParted will fail on every operation that involves an fsck, when in fact the fsck.hfs command is at fault. What do you think?
What version of fsck.hfs are you using? Mine was actually segfaulting on small partitions while checking the catalog file. After fixing that it passed a 30MB partition created using hcreate. My version comes from hfsprogs-332.25 in the oneiric/universe ubuntu apt repo.
Currently I am testing with Kubuntu 11.04. Following is the version information on the hfsprogs package. $ dpkg -l | grep hfs ii hfsprogs 332.25-9 mkfs and fsck for HFS and HFS+ file systems $ I had seen some segfaulting during testing too. This leads me to believe that fsck.hfs has not been thoroughly tested on GNU/Linux, or at least Ubuntu.
I'm inclined to agree. I filed a bug report for the segfault issue. https://bugs.launchpad.net/bugs/912063. After looking at the code that checks the extents and catalog files the only reason for it not to segfault is if an error such as "Invalid allocation block size" is encountered first. Anyway no good trying to integrate this program until it works properly. I keep further discussion of the issue on the launch pad bug.
Thank you Michael for filing the upstream report. If/when the segfault problem is resolved then we can re-visit including your patch in GParted.
(In reply to comment #8) Hi, > After some testing, the fsck.hfs command appears to not have very much use. At > least in it's current state of affairs. > > I tested with the following hfs partition sizes (2 GiB, 1 GiB, 512 MiB, 256 > MiB, 128 MiB, 64 MiB, 32 MiB), and fsck.hfs failed on every one of these newly > created partitions. The output was similar in all cases: One thing that is noteworthy, is that you have tested partitions sizes that are exact powers of 2... As I haven't had any trouble so far using my 50MiB test partition, I ran some tests. On the basis of the results, I suspect that the crashes have been on filesystems that have power-of-2 sizes and were created with hformat from hfsutils, and not with mkfs.hfs from hfsprogs ? The version of GParted I tried does that. Indeed, when I format a partition with a size that is a power of 2 using hformat, then (except for small sizes), fsck.hfs fails. However, if the filesystem is created with mkfs.hfs, or if hformat is used, but the size is not an exact power of 2, then I encounter no problems. So, presumably, this is probably a plain old off-by-one error in hformat. Example session appended. Regards, Rogier. -------------------------------- parted:root ~ 20 # hformat /dev/sdi9 Volume name is "Untitled" Volume was created on Fri Jan 27 22:02:14 2012 Volume was last modified on Fri Jan 27 22:02:14 2012 Volume has 131080192 bytes free parted:root ~ 21 # hformat /dev/sdi10 Volume name is "Untitled" Volume was created on Fri Jan 27 22:02:15 2012 Volume was last modified on Fri Jan 27 22:02:15 2012 Volume has 132112384 bytes free parted:root ~ 22 # hformat /dev/sdi11 Volume name is "Untitled" Volume was created on Fri Jan 27 22:02:16 2012 Volume was last modified on Fri Jan 27 22:02:16 2012 Volume has 133145600 bytes free parted:root ~ 23 # fsck.hfs /dev/sdi9 ** /dev/sdi9 ** Checking HFS volume. ** Checking Extents Overflow file. ** Checking Catalog file. ** Checking Catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. ** The volume Untitled appears to be OK. parted:root ~ 24 # fsck.hfs /dev/sdi10 ** /dev/sdi10 ** Checking HFS volume. Invalid allocation block size (-1, 262142) ** Volume check failed. parted:root ~ 25 # fsck.hfs /dev/sdi11 ** /dev/sdi11 ** Checking HFS volume. ** Checking Extents Overflow file. ** Checking Catalog file. ** Checking Catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. ** The volume Untitled appears to be OK. parted:root ~ 26 # mkfs.hfs -h /dev/sdi9 Initialized /dev/sdi9 as a 127 MB HFS volume parted:root ~ 27 # mkfs.hfs -h /dev/sdi10 Initialized /dev/sdi10 as a 128 MB HFS volume parted:root ~ 28 # mkfs.hfs -h /dev/sdi11 Initialized /dev/sdi11 as a 129 MB HFS volume parted:root ~ 29 # fsck.hfs /dev/sdi9 ** /dev/sdi9 ** Checking HFS volume. ** Checking Extents Overflow file. ** Checking Catalog file. ** Checking Catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled appears to be OK. parted:root ~ 30 # fsck.hfs /dev/sdi10 ** /dev/sdi10 ** Checking HFS volume. ** Checking Extents Overflow file. ** Checking Catalog file. ** Checking Catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled appears to be OK. parted:root ~ 31 # fsck.hfs /dev/sdi11 ** /dev/sdi11 ** Checking HFS volume. ** Checking Extents Overflow file. ** Checking Catalog file. ** Checking Catalog hierarchy. ** Checking volume bitmap. ** Checking volume information. ** The volume untitled appears to be OK. parted:root ~ 32 #
Thank you Rogier for your testing and conclusions. The version of fsck.hfs in fedora 16 also crashes. I passed this note along to Jim Meyering because he had a parted test that would fail due to the fsck.hfs segfault. See the following mailing list post: Re: libparted-fs-resize: HFS/FAT file system resizing library http://lists.gnu.org/archive/html/bug-parted/2012-02/msg00017.html Hopefully soon a patched version of fsck.hfs will be adopted by the major GNU/Linux distributions. In the meantime, I plan to hold off on implementing this patch until the segfault problem is resolved. My concern is that if this faulty fsck.hfs command is enabled in GParted, then HFS shrink operations will incorrectly report error when fsck.hfs segfaults. Also the potential increase in volume for support requests for this segfault error is a concern.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use gparted and if you still see this bug / want this feature in a recent and currently supported version, then please feel free to report it at https://gitlab.gnome.org/GNOME/gparted/-/issues/ by following the guidelines at https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines Thank you for creating this report and we are sorry it could not be implemented so far (volunteer workforce and time is limited).