Package Details: hfsprogs 540.1.linux3-4

Git Clone URL: (read-only, click to copy)
Package Base: hfsprogs
Description: User space utils for create and check Apple HFS/HFS+ filesystem
Upstream URL:
Licenses: custom:APSL
Submitter: Muflone
Maintainer: Muflone
Last Packager: Muflone
Votes: 64
Popularity: 0.78
First Submitted: 2017-10-01 14:46 (UTC)
Last Updated: 2021-02-06 23:33 (UTC)

Pinned Comments

Muflone commented on 2018-12-26 17:19 (UTC)

Package updated to version 540.1 in a specific build compatible with GNU/Linux.

Please do not mark this package out of date since you personally are able to build the package against the newer sources.

Latest Comments

vegas commented on 2021-09-04 07:54 (UTC)

I understood the problem. MacOS turned off due to power failure. After that, HFS file systems are availablу read-only in Linux. If you turn off MacOS correctly, everything works well.

vegas commented on 2021-09-02 20:01 (UTC)

@catniptwinz Yes, fstab has these mounting options. But after updating Archlinux today, HFS is read-only ((

catniptwinz commented on 2021-09-02 19:47 (UTC)

@vegas mount -t hfsplus -o force,rw <src> <dest>

vegas commented on 2021-09-02 19:11 (UTC)

"File system is read-only". I am saddened (( What should I do?

Muflone commented on 2021-02-06 23:33 (UTC)

@davidbrayn fixed, thank you

davidbrayn commented on 2021-02-05 03:42 (UTC) (edited on 2021-02-05 03:43 (UTC) by davidbrayn)

The fedora patches are returning 404.

Looks like the main branch on the fedora repositories have changed from "master" to "rawhide".

If updating the PKGBUILD source URLs to:


And leaving the hashes the same. I was able to get this to build.

nkeck72 commented on 2020-11-30 18:32 (UTC)

I can confirm that lss40770's link worked. Looks like the PKGBUILD is broken.

lss40770 commented on 2020-11-30 03:11 (UTC)

It seems the link to the diskdev_cmds is indeed broken.

However, Void Linux's repo has a working copy of it.

After changing the link for diskdev_cmds to this one I'm able to build the package.

Veazus commented on 2020-11-29 22:41 (UTC)

Is diskdev_cmds still available for download? I get the following error when I try to build this package. Preparing... Cloning hfsprogs build files... Checking hfsprogs dependencies... Resolving dependencies... Checking inter-conflicts...

Building hfsprogs...
==> Making package: hfsprogs 540.1.linux3-2 (Sun 29 Nov 2020 05:36:26 PM EST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Downloading diskdev_cmds-540.1.linux3.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0
  0     0    0     0    0     0      0      0 --:--:--  0:00:02 --:--:--     0
curl: (7) Failed to connect to port 80: No route to host
==> ERROR: Failure while downloading
Failed to build hfsprogs

homelessuser commented on 2020-10-07 16:09 (UTC)

Thanks for fixing this! :)

vegas commented on 2020-09-25 10:20 (UTC)

@keithspg, It works. Thanks!

keithspg commented on 2020-09-22 16:30 (UTC) (edited on 2020-09-22 16:31 (UTC) by keithspg)

Based on @frangio, I edited the PKGBUILD to add this source:


added this patch:

   patch -p1 -i "${srcdir}/hfsplus-tools-sysctl.patch"

regenerated the checksums and it builds. Like I said before, I have no way of testing it. Simple change to the PKGBUILD.

frangio commented on 2020-09-22 15:30 (UTC)

The upstream Fedora fork has a patch for the sysctl issue as well.

homelessuser commented on 2020-09-22 12:48 (UTC)

yay --getpkgbuild hfsprogs
cd hfsprogs


prepare() {
  # Apply patches
  cd "diskdev_cmds-${pkgver}"
  patch -p1 -i "${srcdir}/hfsplus-tools-no-blocks.patch"
  patch -p1 -i "${srcdir}/hfsplus-tools-learn-to-stdarg.patch"
  patch -p0 -i "${srcdir}/ldflags_relro.patch"
  sed -i -e 's/#include <sys\/sysctl\.h>//g' \
    "${srcdir}/diskdev_cmds-540.1.linux3/newfs_hfs.tproj/makehfs.c" \
    "${srcdir}/diskdev_cmds-540.1.linux3/fsck_hfs.tproj/utilities.c" \
    "${srcdir}/diskdev_cmds-540.1.linux3/fsck_hfs.tproj/fsck_hfs.c" \

keithspg commented on 2020-09-14 05:14 (UTC) (edited on 2020-09-14 05:20 (UTC) by keithspg)

I made a patch to comment out the sysctl reference and it builds like @arazaes says. I have no real way to test to see if it actually works, though. This is my patch: add to the patch list and then patch -p1 -i "${srcdir}/sysctl.patch"

arazaes commented on 2020-09-09 10:45 (UTC)

"The removal of sys/sysctl.h from glibc makes this un-build-able."

Yep. It will build if you remove "#include sys/sysctl.h" from Scavenger.h, utilities.c and makehfs.c. I simply created three basic patch files and added them to PKGBUILD to get it to work in the absence of a proper fix.

keithspg commented on 2020-09-07 22:11 (UTC)

Ditto. The removal of sys/sysctl.h from glibc makes this un-build-able.

zed123 commented on 2020-08-22 16:17 (UTC)

Cannot be compiled anymore:

makehfs.c:41:10: fatal error: sys/sysctl.h: No such file or directory 41 | #include <sys/sysctl.h> | ^~~~~~~~~~~~~~ compilation terminated.

glibc 2.32 removed deprecated sysctl.h.

nl6720 commented on 2019-10-09 06:36 (UTC)

Could you add fsck.hfs > fsck.hfsplus and mkfs.hfs > mkfs.hfsplus symlinks?

keithspg commented on 2019-08-06 01:11 (UTC)

please add architecture for RaspberryPi. 'armv6h' and 'armv7h'. Builds correctly on both.

Muflone commented on 2019-03-03 14:39 (UTC)

Apple sources since many years are not compatible with GNU/Linux as they use a lot of libraries and headers unexistant for GNU/Linux.

The package version 540.1 uses a forked project, compatible with GNU/Linux. Just compare the two sources to know why patches cannot be applied to Apple sources.

Rucikir commented on 2019-03-03 13:26 (UTC) (edited on 2019-03-03 13:26 (UTC) by Rucikir)

Hello, I don’t fully understand what’s happening with this package. What I’ve understood is that:

  • Apple does not provide Makefiles and only build diskdev with XCode;
  • You’ve managed to write a Makefile that does the job.

  • Does it only works with version 540?

  • Have you modified something else?
  • Couldn’t we download directly the archive from Apple’s servers and apply the Makefile as a patch, or directly in the PKGBUILD?


Rhinoceros commented on 2019-01-01 00:02 (UTC)

Thanks @Muflone!

Muflone commented on 2018-12-26 17:19 (UTC)

Package updated to version 540.1 in a specific build compatible with GNU/Linux.

Please do not mark this package out of date since you personally are able to build the package against the newer sources.

Nocifer commented on 2018-12-23 13:19 (UTC)

Yes, if it was a case like e.g. Skype, with completely separate versions (and codebases) for each platform, then this package should obviously not be flagged as out of date. But, as already said, the sources are one and the same across all platforms, Linux included, so it's just a matter of building them; a task which Apple has made all but impossible for platforms other than macOS by deprecating the old (via CMake) build process and replacing it with a new one that is compatible with nothing else but Macs (via XCode), but officially the sources are still out there and are still being updated regularly, so in theory anyone can grab them and build the binary for themselves. And by that token it's perfectly conceivable that at any point in the future Some Random Guy (or even Apple itself if it changes its mind) could use the up-to-date sources to create and provide us with fresh, up-to-date instructions for CMake (or even Mason, or whichever other build system).

So, the AUR package being a number of versions behind isn't due to source unavailability or binary incompatibility or licensing issues or for some other insurmountable reason, it's merely a combination of Apple's lack of interest in and/or indirect sabotaging of (take your pick) open source, and an equivalent lack of interest from people on the Linux side who probably find no good reason to waste their time doing Apple's job in order to bypass its shenanigans and build the latest binary with an open source toolchain and then provide us with a proper patch set, and all that for something that isn't even used outside of Apple's small world and is also quite literally crap quality-wise (I'm talking about the HFS+ filesystem here) - it's simply not worth the effort. So it can be done, it just isn't being done. That's imho the very definition of "out of date" as regards to AUR packages.

Finally, there is also the matter of having a not up-to-date package showing as up-to-date on its AUR page, which can be very misleading.

All that said, I get your point of view and I don't completely disagree with the notion that this package is for all intents and purposes at the "latest" version as far as Linux is concerned. And really, it's hfsprogs we're talking about, so I can't say I'm going to lose any sleep over whatever happens to it. For the reasons outlined above I'm for "out of date", but... yeah.

One last thing: I too use yay, but objectively speaking an AUR wrapper's functions are simply its creator's choices, and they should not be used as a basis for AUR policy. As an extremely over the top example, tomorrow yay could introduce a "feature" that notifies you whenever there is an AUR update by making your PC's speaker go permanently beeeeeeeeeeeeep until you update - should that be a reason for making AUR's updates to auto-install?

P.S. - The above are for conversational purposes only, they're not intended as a polemic. If I haven't already stressed it enough: it's hfsprogs we're talking about :P

Rhinoceros commented on 2018-12-21 10:54 (UTC)

Okay, I haven't delved into the background deeply myself. I was interpreting it as the latest version being released as incompatible with Linux, since we would need a Mac to compile it. I imagined that it was analogous to having the newest version of Skype on Windows, but Linux lagging behind. The other thing is that AUR helpers such as yay keep putting up warnings that this package is out-of-date. To me, that generally means that the maintainer is being lax in bumping the version, and I should request an adoption. In a sense, I wouldn't want to know if someone needed to build it on a Mac; also, this would have to be released as hfsprogs-bin… making hfsprogs not out-of-date? However, that's just my interpretation, which is not based on anything official, so I'm happy to be wrong here.

Nocifer commented on 2018-12-21 10:27 (UTC) (edited on 2018-12-21 10:29 (UTC) by Nocifer)

Well, in theory the source is open and cross-platform and it's simply a matter of no one having "bothered" to build the latest version for Linux, so technically speaking this package is out of date, and it should probably stay as it is to reflect that fact. Not to mention that showing as out of date might, at some point in the future, act as motive for someone to rebase the patches and build us a binary, if it's at all possible.

Rhinoceros commented on 2018-12-20 21:46 (UTC)

So it seems that in the Linux world, HFS+ support is stuck at 332 for the foreseeable future

If this is the case, should @Muflone remove the out-of-date flag? This package provides the latest Linux version of hfsprogs.

Nocifer commented on 2018-12-06 22:11 (UTC)

@LukeLR well, at the very least, you would have to take a look at those patches for v332, understand what they're supposed to be doing, decide which parts are still relevant, and adjust them so that they're compatible with v593. Then you would have to install the needed Linux libraries on your Mac, maybe modify Xcode in some way so it can see and utilize them, compile the binary, then distribute it. And you would have to do all this every time one of these libraries receives an update.

As things stand, I think it's safe to say that Apple is deliberately blocking the open source community from using its drivers by making it almost impossible to build them, so unless something changes, we should just accept the facts and make do with what we have until that too stops working. And as I said in my previous comment, "a bit sad in theory (because Linux is usually the king of compatibility between OSes) but mostly irrelevant in practice" because really, who cares about this piece of crap that is HFS+. It would be good to have compatibility, sure, but it's not the end of the world.

user20159 commented on 2018-11-30 00:23 (UTC)

I have a bit of knowledge, and access to a Mac. What would I need to do to compile recent hfsprogs with Xcode and distribute it for Linux?

Muflone commented on 2018-11-02 23:03 (UTC)

I was maintaining this package in the official community repository but I was unable to successfully build a newer version so finally I've decided to drop the package in AUR.

If someone can share some hint to update this package please do. Until then I'm unable to provide further updates.

Nocifer commented on 2018-11-02 12:10 (UTC) (edited on 2018-11-02 12:11 (UTC) by Nocifer)

So I took a peek at , and it seems Apple has stopped providing makefiles for its packages since version 572 (4 releases ago) and has changed the build procedure so that it must be done through Xcode, which pretty much means one needs a Mac to do it.

The latest version with accompanying makefiles is version 557, but it too can't be used because in order to be built properly on Linux this package needs to modify the sourcefiles with some Linux-specific patches, and the Debian package from which it derives those patches is also stuck at version 332.

So it seems that in the Linux world, HFS+ support is stuck at 332 for the foreseeable future (unless some kind soul builds the package on a Mac and then provides us with the compiled binaries).

A bit sad in theory (because Linux is usually the king of compatibility between OSes) but mostly irrelevant in practice. Oh well.

Rhinoceros commented on 2018-10-24 04:05 (UTC)

Hi @Muflone, could you please update this package? diskdev_cmds-593.tar.gz is available now.

2Shirt commented on 2018-03-09 21:10 (UTC)

@Muflone would you mark libbsd as a (make) dependency?