Hacker News Reader

Comment by lxgr | Hacker News Reader

> The implementations of the exfat and msdos file systems on macOS have changed; these file systems are now provided by services running in user-space instead of by kernel extensions.

This sounds interesting!

I really wish there was a native FUSE alternative on macOS; just recently I found myself in a pickle due to not being able to mount an ext4 boot volume on an SD card on my Mac at all. (Passing through to a VM works only via USB.)

View on HN

This and a container story are glaring holes in macOS.

Instead we get widgets on the desktop like it’s 2005 again.

Good ol' Windows Vista

We were doing similar things on the Mac back then by editing plist files :)

I remember creating widgets in windows 98 by setting my desktop wallpaper to a local webpage that had a full-screen background image and some dhtml for interactivity.

One word: Dashboard.

I always get downvoted for this for Craig Ferengi is a pretty boy and has to go.

I gave up and dont say something similar anymore. I am firmly on the Scott Forstall camp.

> I really wish there was a native FUSE alternative on macOS

Isn’t that what DriverKit can be used for?

https://support.apple.com/en-gb/guide/security/secd0a47c14c:

“DriverKit is the framework that allows developers to create device drivers that the user installs on their Mac. Drivers built with DriverKit run in user space, rather than as kernel extensions, for improved system security and stability. This makes for easier installation and increases the stability and security of macOS“

It seems like the only two types of drivers are generic USB device drivers and HID input drivers, though.

There needs to be some OS-side FUSE-like kernel interface for userspace drivers like this to be able to actually mount them in the VFS.

https://developer.apple.com/documentation/fileprovider perhaps?

File Providers are useful in some scenarios, but they are also not really a FUSE equivalent.

They're more geared towards Dropbox-like synchronizing use cases. Some developers have made it work for SSHFS too, but even that's already a bit of a stretch; for more custom solutions it definitely falls short: https://developer.apple.com/forums/thread/681325

The only option currently seems to be to implement a network file server such as SMB (which is what Google Drive used to do before File Providers existed!) or NFS, for which there even is a FUSE bridge available: https://github.com/macos-fuse-t/fuse-t

It's unfortunate that fuse-t follows the same closed source model as MacFUSE did. It's really holding things back.

I was hopeful that Ganesha NFS [1] would suffice as a bridge for the various FUSE filesystems I need to use with macOS, but alas, they have abandoned the FUSE interface and moved to FSAL/FSAL_VFS [2].

It would be really nice to have a clear path to building a copy of Ganesha NFS that supported a whole host of the great FUSE filesystems out there built to this API.

[1] https://github.com/nfs-ganesha/nfs-ganesha [2] https://github.com/nfs-ganesha/nfs-ganesha/issues/759

Watch out for for the Mac SMB client. I found a bug in several MacOS versions which causes the SMB client to send an incorrect file handle in some file requests, causing random files to be deleted which are unrelated to the files you're operating on: https://news.ycombinator.com/item?id=37345855

If you've ever had a suspicion about files on an SMB share going missing, occasionally, when there's been a Mac client using the share, this does indeed happen.

I honestly worry Apple will remember NFS exists at some point and delete that too. File Providers is so limiting.

Me too – I actually only found out it was still around (and not just around, but even supporting v4!) when I looked at fuse-t as an alternative to macFUSE.

That's a scary thought, I depend on mounting NFSv4 files systems. I'm not sure SMB is a replacement, almost certainly wouldn't be as performant [on 10/100 GbE networks].

Don't know if it counts, but RME Audio are now providing drivers for their pro audio gear via DriverKit instead of the ole kext. Installed yesterday, works just fine (modulo checking forums if any widespread issues)

macFUSE - https://osxfuse.github.io/

Yes – I mean a native alternative to this (or even an implementation of it!) which does not need a third-party kernel extension.

I wish they did something so deleting files from the bin wouldn't take millenia on my iMac Pro. Yes, it's an old computer, but shouldn't that be a solved problem?

Not a real fix but doing it from the command line is usually strikingly faster.

I think it's because for some reason they go through an first enumerate the files so they can later show you the progress. But the time spent to enumerate the files is time that could have been spent deleting?

Meanwhile Windows still struggles with getting files to the bin.

Are you referring to the "exclusive advisory locks by default" policy it carried over from MS-DOS? If so, yes, I do feel like that's the worst architectural decision of Windows.

Ultimately, it's what makes software updates as hard as they are there: Just being able to do an "apt-get update" with applications open without anything exploding was a true revelation the first time I used a Unix.

This wasn’t slow for me unless I was deleting a node_modules folder or something with a gazillion files in it. Sounds like something’s weird on your not-that-old iMac Pro.

I'm genuinely curious, why does this take so long?

I can't even begin to imagine. If I'm deleting 200 files on my M1 MBA, that's still going to take 30-45 seconds.

It's doing something. What is it doing? Does it have something to do with Time Machine or file versioning or secure erase or what?

Everything else is blazingly fast as it should be.

I reluctantly did buy Extfs from Paragon for this. It's too expensive I think, but there are just no free opensource solutions.

Doesn't that require breaking glass in Secure Boot these days, just like macFUSE?

I'm not really willing to install a third-party kernel extension just for a custom file system I need once every few months anymore, especially given that Apple's native exFAT drivers now apparently run in the userspace.

They should just make that capability available to the actual-userspace!

> Doesn't that require breaking glass in Secure Boot these days

You mean turning off system integrity protection? No. I have both ext4 and NTFS from Paragon, and didn't have to do that.

Not SIP, but you do need to reboot and change some things in recoveryOS involving Secure Boot (or however Apple's equivalent is called), right?

https://developer.apple.com/documentation/apple-silicon/inst...

Not here. I do have an intel CPU though, maybe it's different with an Apple CPU?

Yes, this is an M1/M2 thing only (at least for now).

Apple's secure boot process differs significantly between Intel and Apple CPU.

Reply on news.ycombinator.com