Update install scripts for Yosemite and later

[adespoton]

Since Yosemite and later lock down the /System directory, and we shouldn't be writing anything there in the first place, I suggest changing the install location to /Lib/Filesystems/ instead of /System/Lib/Filesystems/ .

Also, the postinstall script also no longer works.

chown root:wheel /System/Library/Filesystems/fusefs_hfs.fs
ln -fs /System/Library/Filesystems/fusefs_hfs.fs/Contents/Resources/fusefs_hfs /sbin/mount_fusefs_hfs

This should change to

chown root:wheel /Library/Filesystems/fusefs_hfs.fs
ln -fs /Library/Filesystems/fusefs_hfs.fs/Contents/Resources/fusefs_hfs /usr/local/sbin/mount_fusefs_hfs

The Distribution script looks fine.

[thejoelpatrol]

Thanks for figuring this out! Hopefully I can try this soon, since this is simple enough. I have a 10.11 machine now so I can try it.

[JayBrown]

Is it already compatible with FUSE for macOS v3.5.2 (except for the install scripts, of course)?

PS: I second the integration of libmfs for Macintosh File System support. :)

[adespoton]

I may have figured out why he put it in /System... due to load order, the default HFS driver appears to override this one if it's not there. This means that you may need to disable SIP under 10.11 and 10.12 to get it to actually work. :(

On Oct 5, 2016, at 4:52 AM, Joss Brown notifications@github.com wrote:

Is it already compatible with FUSE for macOS v3.5.2 (except for the install scripts, of course)?

PS: I second the integration of libmfs for Macintosh File System support. :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[JayBrown]

I opened the pkg with Pacifist and Suspicious Package, and both confirm that the installer will put it into the system library. This should be avoided (and changed). Until then you can manually extract it into the global library with the above applications… then manually symlink into /usr/local/sbin/

PS: works with FUSE 3.5.2? Works on Sierra?

[adespoton]

See my previous response; works with the latest FUSE for OS X, but SIP will get in the way of it installing in /System, and installing in /Library appears to get it overridden by the default HFS driver. So you'll need to reboot and disable SIP, install, then enable SIP again.

On Oct 5, 2016, at 3:39 PM, Joss Brown notifications@github.com wrote:

I opened the pkg with Pacifist and Suspicious Package, and both confirm that the installer will put it into the system library. This should be avoided (and changed). Until then you can manually extract it into the global library with the above applications.

PS: works with FUSE 3.5.2? Works on Sierra?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[JayBrown]

I have disabled SIP anyway, so installing into /System/Library is possible right away. I'm just not comfortable with it, that's all. An update that makes it work in /Library/ would be preferable.

[JayBrown]

I have tested it now, with fusefs_hfs.fs extracted to /System/Library/Filesystems and chowned as root:wheel, and the symlink mount_fusefs_hfs in /sbin, but it doesn't work: tried to open a dmg, converted from an .img file, which contains an old HFS volume, but OS X says no mountable filesystems (10.11.6). (Or do I have to reboot first? To my knowledge this shouldn't be necessary with FUSE filesystems.)

[thejoelpatrol]

Finally playing with this today. Apparently SIP also protects /sbin, not just /System, so I'll change that as well. I'll see what I can figure out overall.

@JayBrown if you want to use MacFUSE with 10.6, can you continue using the original fusehfs? Oh, as I write this, I see that Jesús has taken it down. Hmm, would it help if I built the old version 0.1.3 again?

[JayBrown]

I'm on 10.11.6, i.e. El Capitan, soon Sierra, so I'm trying to make it work on the current system with FUSE for macOS 3.5.2, but with MacFUSE backward compatibility enabled.

[thejoelpatrol]

Ah, sorry, all these name changes are tripping me up (MacFUSE --> FUSE for OS X --> FUSE for macOS). Indeed you do need MacFUSE backward compatibility installed.

[thejoelpatrol]

This bug report basically describes our problem, I think. Unclear if this is still 100% current, or if Apple is planning on changing this.

Something I didn't fully grasp earlier (I haven't looked at this in a couple years now) is that the fs bundle doesn't need to do anything to register itself with the kernel or anything osxfuse related, it just needs to be in /System/Library/Filesystems. <sys/loadable_fs.h> defines this location, which is used in our case in diskarbitrationd's DASupport.c. To make this work previously, our Info.plist sets FSProbeOrder to 900 for Apple_HFS (the value in the built-in hfs.fs is 1000, and lower values are probed first). I'm still working on figuring this all out, but for now it does look to me like the bundle may need to be in /System.

Another issue is /sbin. A thread on the osxfuse mailing list seems to suggest that other devs have been able to use /usr/local, but I can't even make /usr/sbin work, let alone /usr/local (of note, /usr/sbin seems like it should work, according to mount.c)

As of now, it does mostly work for me when I have the bundle in /System and the mount command/link in /sbin, though it doesn't show up in the list of Devices, I have to go look for it directly in /Volumes. I'll probably ask on the osxfuse mailing list if anyone with experience with SIP can weigh in on our situation, since I'm at least part of the way there now. I am not ready to completely declare defeat against SIP yet, since others have made it work somehow.

...but they probably weren't competing with a built-in filesystem. One thing that is a little disheartening is that there is another module that assumes priority over a built-in filesystem bundle, NTFS, and they apparently require you to disable SIP while installing.

[thejoelpatrol]

Ah, this explains why I couldn't attach to mount with lldb.

A thought occurred to me that I'll investigate. It's still possible to create third-party kernel modules, you just need a codesigning certificate from Apple. Maybe that would allow us to put a third-party filesystem in /System, as well. I'll ask around when I get a chance.

[d235j]

@thejoelpatrol Is that Apple bug still a problem in recent versions of macOS (10.13, 10.14)? It seems that Tuxera NTFS works fine with only a .fs bundle in /Library/Filesystems (no /sbin anymore either). Tuxera NTFS has a very similar use case as FuseHFS — replacing the macOS-provided read-only NTFS driver with a read/write one.

It's possible they made a lot of noise to Apple, and Apple fixed it due to NTFS being so much more widely deployed.

[thejoelpatrol]

@d235j Interesting, that is worth a look, thanks. I'm still on 10.12 but I will probably upgrade once 10.14 settles down.

[adespoton]

@thejoelpatrol Looks like Apple's done it again; this needs to be installed in userland now, and probably needs to be notarized. At least HFS support has been pulled completely, so that issue of Apple HFS overriding it isn't a problem anymore.

[gingerbeardman]

Are there latest steps to install this successfully @adespoton ? I'm on Big Sur.

[adespoton]

Hey @gingerbeardman — I haven’t had time to dig into it recently. @thejoelpatrol , have you had any time to try it in a userland configuration?

As I said in my previous comment, it will also need to be signed and notarized now to function. My dev account is currently inactive, so someone else will have to do that.

[gingerbeardman]

I can do that if everything else checks out OK.

[thejoelpatrol]

It's been a while since I've been able to think about this. I have some vacation now and would like to get this higher up on my list, though I have a couple other demands as well. I'll see if I can take a look next week and understand the current situation. I have one Mac on 10.14 that I will probably start with, but another than can be updated to 12 which is probably what matters most. It's probably good that HFS support is gone entirely now; that should help.

[adespoton]

Yeah; a lack of HFS and MFS in the OS means we should have fewer issues with a fsbundle. The big issue is going to be the userland requirement for 12+ -- that can be tested in 10.15 and up.

[thejoelpatrol]

I see what you mean about userland, @adespoton. I think you're referring to the separate System and Data volumes in 10.15, and the Sealed System Volume in 11?

I have a little bit of bad news about the "removal" of HFS support in 10.15. /System/Library/filesystems/hfs.fs is still there because it also provides support for HFS+, and the Info.plist within it still refers to standard HFS and HFS+, e.g. pointing to /sbin/mount_hfs for mounting both of them. Now, it's true that mounting a standard HFS disk image no longer works, but it doesn't entirely not work. In the system log console, I see diskarbitrationd trying to figure out what to do with it:

default 20:06:33.290899-0500    diskarbitrationd      copied disk description, id = /dev/disk2.
default 20:06:34.332961-0500    diskimages-helper   /sbin/fsck_hfs(/dev/disk2) failure for /Users/joel/hfs/Disk608.img.
default 20:06:35.537086-0500    diskarbitrationd      copied disk description, id = /dev/disk2.
default 20:06:35.537864-0500    diskarbitrationd      queued solicitation, id = 0000000000000001:0000000000000001, kind = disk mount, disk = /dev/disk2, options = 0x00000000.
default 20:06:35.538228-0500    diskarbitrationd      probed disk, id = /dev/disk2, with udf, ongoing.
default 20:06:35.546263-0500    diskarbitrationd      probed disk, id = /dev/disk2, with udf, failure.
default 20:06:35.546483-0500    diskarbitrationd      probed disk, id = /dev/disk2, with apfs, ongoing.
default 20:06:35.552043-0500    diskarbitrationd      probed disk, id = /dev/disk2, with apfs, failure.
default 20:06:35.552216-0500    diskarbitrationd      probed disk, id = /dev/disk2, with hfs, ongoing.
default 20:06:35.569077-0500    diskarbitrationd      probed disk, id = /dev/disk2, with hfs, success.

As of Catalina, the hfs.util within hfs.fs used to probe new devices still claims this as something it can handle.

Of course, it still eventually fails:

default 20:06:35.569287-0500    diskarbitrationd      dispatched callback, id = 0000000000000004:0000000000000004, kind = disk mount approval, disk = /dev/disk2.
default 20:06:35.570420-0500    diskarbitrationd      dispatched response, id = 0000000000000004:0000000000000004, kind = disk mount approval, disk = /dev/disk2, approved.
default 20:06:35.571154-0500    diskarbitrationd      mounted disk, id = /dev/disk2, ongoing.
default 20:06:35.582549-0500    diskarbitrationd      mounted disk, id = /dev/disk2, failure.
default 20:06:35.582591-0500    diskarbitrationd    unable to mount /dev/disk2 (status code 0x00000001).
default 20:06:35.582622-0500    diskarbitrationd    unable to mount /dev/disk2 (status code 0x00000001).
error   20:06:35.582643-0500    diskarbitrationd    unable to mount /dev/disk2 (status code 0x00000001).
default 20:06:35.582968-0500    diskarbitrationd      dispatched callback, id = 0000000000000001:0000000000000001, kind = disk mount, disk = /dev/disk2, status = 0x0000C001.
default 20:06:35.581712-0500    kernel  hfs_mount: hfs_mountfs returned error=22 for device disk2

I'm upgrading my Catalina machine to Big Sur now to see if any of this has changed.

Even if it has not, maybe we can learn something from Tuxera NTFS, mentioned above. This seems to be the commercial version of the macFUSE NTFS-3G port. As of about 2 months ago, that page said installing NTFS-3G required disabling SIP and replacing /sbin/mount_ntfs while in recovery mode, and said they did not know how to support the system volume in Big Sur yet. BUT!! the commercial Tuxera NTFS looks like they recently added support for Monterey, so apparently they figured it out? I don't mind buying a copy of that, since I'd like to be able to write to NTFS drives anyway, so maybe we can reverse engineer how they are doing it.

[thejoelpatrol]

The good news:

The situation described above with HFS in 10.15 is indeed changed in 12. It doesn't look to me like hfs.util in hfs.fs is asserting compatibility any more.

10.14:

joel$ /System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util -p disk3 removable readonly
joel$ echo $?
255
joel$ /System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util -p disk3 removable writable
joel$ echo $?
255

12.1:

joel$ /System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util -p disk3 removable readonly
joel$ echo $?
254
joel$ /System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util -p disk3 removable writable
joel$ echo $?
254

return codes of -1 and -2, very mysterious...unless you have darwin open source ;) https://opensource.apple.com/source/hfs/hfs-556.60.1/hfs_util/hfsutil_main.c.auto.html line 420 : returns FSUR_IO_SUCCESS if OK else one of the other FSUR_xyz errors in loadable_fs.h.

https://opensource.apple.com/source/xnu/xnu-7195.81.3/bsd/sys/loadable_fs.h.auto.html

/*
 * Return codes from .util program
 */
#define FSUR_RECOGNIZED         (-1)    /* response to FSUC_PROBE; implies that
                                     * a mount is possible */
#define FSUR_UNRECOGNIZED       (-2)    /* negative response to FSUC_PROBE */

My reading of this is that it seems like the built-in HFS support is more removed now.

The bad news

Tuxera NTFS, which we know works (I have verified it does allow NTFS write support on 12.1 without any weird steps) installs a kext, not only some macFUSE stuff. I don't know what it does, it might be for integrating with Disk Utility on a deeper level. But it also might be more complicated. I don't feel like disassembling the kext because reverse engineering is my job, so I'm going to ask them and see if they are willing to explain :)

[adespoton]

Sorry, I should have been more clear.

In 10.15, Apple introduced a new userland-only API for adding file systems, similar to the userland kext replacement required for network and file interception. With 11, anything using the old method had to be signed with a signature on an allow list, or it would warn that the method being used was deprecated. With 12, the capability was removed completely for components not signed by signatures on the allow list.

It appears Tuxera has gone the “allow-list our really important third party kext” route — this likely won’t survive to macOS 14, so they’ll need to come up with a userland reimplementation. The good news is, Apple actually provides some sample code on how to do it — I read through it a year or so ago, and will see if I can dig it up in the ADC docs.

On Jan 2, 2022, at 8:58 PM, thejoelpatrol @.***> wrote:

 The good news:

The situation described above with HFS in 10.15 is indeed changed in 12. It doesn't look to me like hfs.util in hfs.fs is asserting compatibility any more.

10.14:

joel$ /System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util -p disk3 removable readonly joel$ echo $? 255 joel$ /System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util -p disk3 removable writable joel$ echo $? 255 12.1:

joel$ /System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util -p disk3 removable readonly joel$ echo $? 254 joel$ /System/Library/Filesystems/hfs.fs/Contents/Resources/hfs.util -p disk3 removable writable joel$ echo $? 254 return codes of -1 and -2, very mysterious...unless you have darwin open source ;) https://opensource.apple.com/source/hfs/hfs-556.60.1/hfs_util/hfsutil_main.c.auto.html line 420 : returns FSUR_IO_SUCCESS if OK else one of the other FSUR_xyz errors in loadable_fs.h.

https://opensource.apple.com/source/xnu/xnu-7195.81.3/bsd/sys/loadable_fs.h.auto.html

/*

• Return codes from .util program */

  define FSUR_RECOGNIZED (-1) /* response to FSUC_PROBE; implies that

                             * a mount is possible */

  define FSUR_UNRECOGNIZED (-2) / negative response to FSUC_PROBE /

  My reading of this is that it seems like the built-in HFS support is more removed now.

The bad news

Tuxera NTFS, which we know works (I have verified it does allow NTFS write support on 12.1 without any weird steps) installs a kext, not only some macFUSE stuff. I don't know what it does, it might be for integrating with Disk Utility on a deeper level. But it also might be more complicated. I'm going to ask them and see if they are willing to explain.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.

[thejoelpatrol]

The good news is, Apple actually provides some sample code on how to do it — I read through it a year or so ago, and will see if I can dig it up in the ADC docs.

I'll be interested to see that to understand what it's all about. But if that's what's actually required, I'm not sure if I'll make that leap. I wrote some Swift once, and it was OK, but I'm not actually a big time Apple dev.

But is it really going to be required? The thing about FUSE is that it's already mostly in userspace at the level we're using. macFUSE itself does require a kext, so they might need to upgrade, and I don't know their plan in that regard. But we haven't needed our own kext in the past, just a few regular executables inside the .fs bundle. I've just asked on the macFUSE mailing list if they have a plan regarding the deprecation of kexts.

This person seems to suggest that the File Provider API is not quite ready for the kind of thing we're trying to do, an actual full file system: https://developer.apple.com/forums/thread/681325

[gingerbeardman]

I know Quinn from my time at Apple and he knows his stuff.

[thejoelpatrol]

A bit of good news. When I place my latest fs bundle in /Library/Filesystems, diskutil reports that HFS is an available filesystem now, whereas before it was not:

joel$ diskutil listFilesystems
Formattable file systems

These file system personalities can be used for erasing and partitioning.
When specifying a personality as a parameter to a verb, case is not considered.
Certain common aliases (also case-insensitive) are listed below as well.

-------------------------------------------------------------------------------
PERSONALITY                     USER VISIBLE NAME
-------------------------------------------------------------------------------
Case-sensitive APFS             APFS (Case-sensitive)
  (or) APFSX
APFS                            APFS
  (or) APFSI
ExFAT                           ExFAT
Free Space                      Free Space
  (or) FREE
HFS                             HFS Standard (FuseHFS)
MS-DOS                          MS-DOS (FAT)
MS-DOS FAT12                    MS-DOS (FAT12)
MS-DOS FAT16                    MS-DOS (FAT16)
MS-DOS FAT32                    MS-DOS (FAT32)
  (or) FAT32
HFS+                            Mac OS Extended
Case-sensitive HFS+             Mac OS Extended (Case-sensitive)
  (or) HFSX
Case-sensitive Journaled HFS+   Mac OS Extended (Case-sensitive, Journaled)
  (or) JHFSX
Journaled HFS+                  Mac OS Extended (Journaled)
  (or) JHFS+
Tuxera NTFS                     Windows NT File System (Tuxera NTFS)

AFAICT this means we are past the problem previously caused by built-in HFS support. It's still not working, but I'm breathing a sigh of relief on that one, at least.

[d235j]

Tuxera NTFS, which we know works (I have verified it does allow NTFS write support on 12.1 without any weird steps) installs a kext, not only some macFUSE stuff. I don't know what it does, it might be for integrating with Disk Utility on a deeper level.

I believe this kext is a "private label" version of the open source macFUSE, or a licensed version of Benjamin Fleischer's macFUSE but with bundle ID and library changes to prevent conflicts. I haven't analyzed it that deeply yet, though.

Tuxera NTFS allowed for seamless read/write NTFS support in every macOS version so far, without the requirement to disable SIP. While it does require loading a kext, this is no different than macFUSE.

I am hoping that Apple comes out with a proper FUSE-like API in the next version of macOS, because the File Provider API is indeed inadequate for these purposes.

[thejoelpatrol]

I've made a tiny bit of progress. diskarbitrationd will now launch our probe command to see if our filesystem can handle an HFS disk image, and finding that it can, it attaches it in /dev. Mounting isn't working yet. But we're getting there.

---

For anyone's future reference trying to debug diskarbitrationd, here are some tips. You'll need to disable SIP for some of this.

Launching apps is not possible while diskarbitrationd is halted. Don't halt for too long (>5min?) or something will break and you'll need to reboot.

To see any diskarbitrationd messages in console, you'll need to do this: https://georgegarside.com/blog/macos/sierra-console-private/ But you will only see a few select lines in the console app, very frustrating.

So you probably want to invoke diskarbitrationd with logging on its next run (kill -9 to make launchctl restart it): $ sudo launchctl debug system/com.apple.diskarbitrationd -- /usr/libexec/diskarbitrationd -d its full log is then written to /var/log/diskarbitrationd.log;

Attach lldb to diskarbitrationd: $ sudo launchctl attach system/com.apple.diskarbitrationd Since you don't have debugging symbols, you'll want a good disassembly to show you the way. IDA is good :)

Find ASLR base of the process you are attached to in lldb: (lldb) image dump sections

In my case, one problem so far was related to a path being wrong in DAFileSystemProbe, resulting in ENOTSUP (0x0000002D) being reported in __DAProbeCallback. A path in memory may be a CFURL or CFURLRef, which Apple calls an "opaque type". Given a pointer to a CFURL, the string you're probably looking for containing the actual path can be found like so:

struct CFURL {
  long field1;
  long field2;
  long field3;
  struct some_other_type *field4;
  ...
};

struct some_other_type {
  long field1;
  long field2;
  char path[];
  ...
};

And finally, for anyone else coming from gdb, here's a nice lldb cheat sheet: https://lldb.llvm.org/use/map.html

[joevt]

Is this issue just about getting automatic HFS support in Monterey? Because manual mounting does work (see top of readme at https://github.com/joevt/fusehfs )

[gingerbeardman]

Just confirmed @joevt's readme/fork and mounted manually (Big Sur)

[thejoelpatrol]

@joevt yes, mounting automatically has basically been the issue since this 2015 or thereabouts. We want people to be able to double click an image and mount it. AFAIK it was possible for a while to run the utilities manually if you had them handy. I see in your fork that you've updated it for the latest macFUSE, which I think mine is tripping over right now during the mount step. I'll review your commits. Pretty sure it's fully solvable at this point, now that the built-in Apple hfs.fs isn't asserting compatibility with HFS. Thanks for the nudge.

[thejoelpatrol]

As for the issue of kext deprecation and FileProvider and all that, the developer of macFUSE responded to me on the mailing list. He wrote a very nice in-depth answer to my question about whether macFUSE was going to be there in the future given the kext situation, but ultimately it boiled down to this paragraph:

The macFUSE functionality cannot be moved to the File Provider API. macFUSE is more versatile than 
File Providers. File System kernel extensions have not been deprecated by Apple, yet. I expect Apple 
to release a new user space API for developing full-featured file systems. I will do my best to update 
macFUSE to use this new API instead of the old kernel API as soon as the new API becomes available.

[adespoton]

If someone solves this, please flag it up. I’m dealing with the same issue on Apple’s built-in 9P filesystem that will present a virtual file system to the OS — I’m considering it as a potential replacement for MacFUSE, modifying hfsutils to present a 9P virtual filesystem and then mounting it. But lack of auto mount is an issue there too.

-Em

On Jan 21, 2022, at 6:42 PM, thejoelpatrol @.***> wrote:

 @joevt yes, mounting automatically has basically been the issue since this 2015 or thereabouts. We want people to be able to double click an image and mount it. AFAIK it was possible for a while to run the utilities manually if you had them handy. I see in your fork that you've updated it for the latest macFUSE, which I think mine is tripping over right now during the mount step. I'll review your commits. Pretty sure it's fully solvable at this point, now that the built-in Apple hfs.fs isn't asserting compatibility with HFS. Thanks for the nudge.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.

[thejoelpatrol]

I had already made most of the changes that @joevt has over in his fork, but he had a few I didn't, which seem to be helpful (e.g. updating some libraries to link against). With our powers combined, I now have auto mounting kind-of sort-of working. When I double click an image, it gets sent to our filesystem, which can handle it and which does mount it, but there are some issues. The OS insists on mounting it read-only and I'm not sure resource forks are working. But I think we're getting closer. Automatically mounting images and reading files is better than I had before.

Also, I was having issues with the macFUSE kext loading at all on my system, as described here: https://github.com/osxfuse/osxfuse/issues/315 I followed the trick there of removing SMB and manually inserting macFUSE. Not ideal, but also not our fault or within our control.

[joevt]

I had recently been using fusehfs to access resource forks on an hfs disk image. I used Resorcerer (it supports decompressing compressed resources and reading ROM resources) in Mac OS 9 (with SheepShaver) to copy icons from the System file, the System Resources file, and the System ROM Resources and saved them to a resource file on the Mac OS 9 disk image. I used fusehfs to mount the disk image in macOS so I could extract the icons from the resource file for testing with my new code in RefindPlus to draw any icon type from an icns file. https://github.com/joevt/RefindPlus/commit/b6fe6c0fce8de1b8572c0fc73da5f580981c4e22

The @ option to ls will show which files have a resource fork (shown as an extended attribute with name com.apple.FinderInfo) ls -l@ /Volumes/1/Desktop\ Folder

-rwxr-xr-x@ 1 root  wheel  0 Nov 12 19:23 systemcluts.rsrc
    com.apple.FinderInfo    32 
    com.apple.ResourceFork  2614 

You can view the contents of extended attributes like this: xattr -px com.apple.FinderInfo /Volumes/1/Desktop\ Folder/systemcluts.rsrc | xxd -p -r | xxd

00000000: 5253 5243 446f 7567 0100 0060 0978 0000  RSRCDoug...`.x..
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................

You can view the list of resources like this: derez -p -only xxxx /Volumes/1/Desktop\ Folder/systemcluts.rsrc

derez V3.7
Copyright Apple Computer, Inc. 1986-2018

/Volumes/1/Desktop Folder/systemcluts.rsrc: ### derez - Skipping 'clut' (1, sysheap, locked, protected).
/Volumes/1/Desktop Folder/systemcluts.rsrc: ### derez - Skipping 'clut' (2, sysheap, locked, protected).
/Volumes/1/Desktop Folder/systemcluts.rsrc: ### derez - Skipping 'clut' (4, sysheap, locked, protected).
/Volumes/1/Desktop Folder/systemcluts.rsrc: ### derez - Skipping 'clut' (8, sysheap, locked, protected).

[thejoelpatrol]

Thank you for those tips @joevt. Looks like xattr doesn't support hex display in Monterey any more, and Apple isn't shipping a man page for derez these days either, but I found it online. From your tips I confirmed that actually resource forks are indeed working as extended attributes, so that's one less thing to worry about.

[thejoelpatrol]

Good news. I have everything working. Double clicking a disk image mounts it read-write with resource forks and it shows up in the Finder sidebar. Unmounting works.

I need to clean up a few loose ends and debugging stuff, and test with SIP re-enabled, but I don't expect any problems. At this point I just need to make a new Installer pkg, since the old one was made with PackageMaker, which doesn't work any more.

We made it!!

...for how long? There's still the outstanding question of whether macFUSE may some day get caught up in the great kext extinction, if there are any issues moving it to some theoretical new future API. Dropbox and Microsoft just got their filesystem kexts booted since they can move them to FileProvider. Anyway, until then, it looks like we get to play with our antique disks a while longer.

[adespoton]

That’s great news! Any chance of adding your MFS support to this too?

-Em

On Jan 30, 2022, at 7:19 PM, thejoelpatrol @.***> wrote:

 Good news. I have everything working. Double clicking a disk image mounts it read-write with resource forks and it shows up in the Finder sidebar. Unmounting works.

I need to clean up a few loose ends and debugging stuff, and test with SIP re-enabled, but I don't expect any problems. At this point I just need to make a new Installer pkg, since the old one was made with PackageMaker, which doesn't work any more.

We made it!!

...for how long? There's still the outstanding question of whether macFUSE may some day get caught up in the great kext extinction, if there are any issues moving it to some theoretical new future API. Dropbox and Microsoft just got their filesystem kexts booted since they can move them to FileProvider. Anyway, until then, it looks like we get to play with our antique disks a while longer.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.

[thejoelpatrol]

@adespoton oof, that's a whole other project. We can turn our attention to #1 once this is all squared away. I will say that it would probably make sense to do it sooner rather than later now that this is fresh in my mind. But no promises...

[joevt]

Looks like xattr doesn't support hex display in Monterey any more

The -px option of xattr works fine in Montery 12.1. I just installed Monterey 12.2 and it still works. Maybe you typed the command incorrectly?

[thejoelpatrol]

@joevt

joel$ xattr -px com.apple.ResourceFork /Volumes/System\ Startup/TeachText
option -x not recognized

usage: xattr [-slz] file [file ...]
       xattr -p [-slz] attr_name file [file ...]
       xattr -w [-sz] attr_name attr_value file [file ...]
       xattr -d [-s] attr_name file [file ...]

Strange, doesn't work on my 12.1 system. In any case, the resource forks are there and I can read them with derez.

[thejoelpatrol]

While I work on the installer package, anyone who wants to build the .fs bundle and install it yourself manually (in /Library/Filesystems) is welcome to test it out.

[joevt]

Does the man page show the -x option? It should also say macOS 12.1 November 29, 2010 at the bottom.

joevt@Joes-Mac-Pro ~ % man xattr
joevt@Joes-Mac-Pro ~ % xattr
Not enough arguments for option -?. Expected at least 1 but got 0

usage: xattr [-l] [-r] [-s] [-v] [-x] file [file ...]
       xattr -p [-l] [-r] [-s] [-v] [-x] attr_name file [file ...]
       xattr -w [-r] [-s] [-x] attr_name attr_value file [file ...]
       xattr -d [-r] [-s] attr_name file [file ...]
       xattr -c [-r] [-s] file [file ...]

The first form lists the names of all xattrs on the given file(s).
The second form (-p) prints the value of the xattr attr_name.
The third form (-w) sets the value of the xattr attr_name to the string attr_value.
The fourth form (-d) deletes the xattr attr_name.
The fifth form (-c) deletes (clears) all xattrs.

options:
  -h: print this help
  -l: print long format (attr_name: attr_value and hex output has offsets and
      ascii representation)
  -r: act recursively
  -s: act on the symbolic link itself rather than what the link points to
  -v: also print filename (automatic with -r and with multiple files)
  -x: attr_value is represented as a hex string for input and output
joevt@Joes-Mac-Pro ~ % where xattr
/usr/bin/xattr
joevt@Joes-Mac-Pro ~ % file /usr/bin/xattr
/usr/bin/xattr: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/xattr (for architecture x86_64):   Mach-O 64-bit executable x86_64
/usr/bin/xattr (for architecture arm64e):   Mach-O 64-bit executable arm64e
joevt@Joes-Mac-Pro ~ % ls -l@ /usr/bin/xattr
-rwxr-xr-x  1 root  wheel  135216  7 Dec 15:39 /usr/bin/xattr
joevt@Joes-Mac-Pro ~ % md5 /usr/bin/xattr
MD5 (/usr/bin/xattr) = b453faa88579da864236c4649dac9213

[gingerbeardman]

option -x not recognized

FWIW, I also get this on Big Sur.

[joevt]

@gingerbeardman - is the man page different (the macOS version and date in the man output)? Is the command in a different place (found with where)? Is the command an x86/arm universal binary (use file)? Is the file size different (use ls)? Is the contents different (use md5)? Do you have Xcode installed? I know this is kind of off topic but it's weird.

[adespoton]

While I work on the installer package, anyone who wants to build the .fs bundle and install it yourself manually (in /Library/Filesystems) is welcome to test it out.

Hmm... I went to build it on my M1, and XCode is fighting with me about targets and throwing linking errors. Seems like the code doesn't like ARM and the compiler doesn't like 32-bit.

[gingerbeardman]

man page different (the macOS version and date in the man output)

It is the same.

I'll check the other things later.

I do have Xcode installed.

[adespoton]

I've got a request for one of you who's been able to deploy the updated version: can you test what happens if you create an empty HFS SparseBundle image under macOS 10.15-12? Without FuseHFS installed, the image will be the maximum disk size. Under Mojave, it should be around 8Kb. Just wondering if implementing HFS enables partition pruning again.

[thejoelpatrol]

@adespoton it looks like creating new volumes doesn't work yet. That'll be future work =/

Or did you mean HFS+? I created one of those with a max size of 100MB. It came out to 20MB. This is on macOS 12.1

[thejoelpatrol]

I'm working on the installer package. I have it installing correctly, and it seems to work after installing. I'm waiting on my Apple Developer account to be activated so I can try signing it.