Departure from OSX Fuse using File Provider framework?

[wrobelda]

Summary

macOS extensions are on the way out, to be replaced by the File Provider Framework, already known from iOS/ipadOS: https://developer.apple.com/documentation/fileprovider

Some new products began to appear using it: https://www.expandrive.com/strongsync/ https://news.ycombinator.com/item?id=26334101

I am not sure, however, if it is possible to stack multiple providers – from what I understand, Cryptomator would have to add a native support for each cloud backend.

[overheadhunter]

Yes, we will take a closer look definity!

[raveslave]

+1

[Kaiyangshi-Ito]

Could adding support for iCloud easier/coming sooner? Since apple doesn't care for its buggy webDAV anymore, this is really needed for many of us.

[McBoerny]

+1 on this. Adopting this API sounds like it would be possible to

• get rid of FUSE and WebDAV in general
• removing complexity of installations
• removing dependancy on third party implementations (easier audits)
• providing a native integration experience to end-users
• likely more stability
• potentially being able to use trashcan capability?

[julesallen]

+1 on this. Adopting this API sounds like it would be possible to

I would hope that things like Tags would magically start working as well? I miss those a lot.

[nsakibp]

Any update on this please? anyone?

[MalEbenSo]

I use 1.7.3 with FUSE-T.

The "experimental" status causes me some uncomfortable feelings.

Other than that, no problems whatsoever so far.

[tobihagemann]

We were actually experimenting with the File Provider Framework last year but it works fundamentally different from our current approach and stopped our experiments.

With the newly added support for FUSE-T, we now have a viable solution for Apple Silicon Macs (which we hadn't before with macFUSE/WebDAV). We hope we can get out of the experimental status soon, it already made tremendous progress in the last months.

File Provider support on macOS would require us to write a new app from scratch, which is currently not on our roadmap.

Edit: And I guess there is also a different answer on this subject, which is about our long-term vision. 😄 https://community.cryptomator.org/t/native-macos-support-and-removing-the-need-for-fuse/11971/2

[basepi]

For the record, I’ve had a bunch of stability issues with FUSE-T as well on my M1 MacBook Pro. If it gets into a bad state I have to hard reboot my mac. Started using WebDAV for awhile but that has its own major issues as you know.

I do not think the current status quo is acceptable for arm macs. I hope that rewrite gets us closer to native support because right now I’m seriously considering looking elsewhere. It’s just too unstable and I want to use it for important data.

As an aside, would it be worth trying to close some of these threads as duplicates? #2867, #2299 to name a couple.

[overheadhunter]

@basepi Thanks for the factual comment (these are rare when something doesn't work as expected). We're aware that FUSE-T can't be considered stable yet, as it just recently made its debut. Since the File Provider API works completely different on a conceptional level, this will only be a long-term goal, requiring a rewrite of core parts of Cryptomator (consider it a major version bump). For now we can only hope that fuse-t will continue to gradually improve over time, so we can eventually mark it as production-grade.

Yes, those two are mostly duplicates. Thanks for the hint!

[MalEbenSo]

I have never had an issue with FUSE-T, but … never say never, so out of interest:

Are there known cases where the crash led to data corruption?

Are the stability problems traced to FUSE-T and must be fixed there, or are they happening within Cryptomator-code?

Since others see them regularly, whereas I have never seen a stability problem. Could it be that [OT] is tied to how long the app runs (e. g. memory leak), because I typically let Cryptomator only run for a few hours and quit it when I am done. Sometimes I forget, and it runs into the next day, but never longer.

Overall: Difficult situation right now. I am thankful for the work that is put into Cryptomator, I really like the app.

[MalEbenSo]

For the record, I’ve had a bunch of stability issues with FUSE-T as well on my M1 MacBook Pro. If it gets into a bad state I have to hard reboot my mac.

Afaik both FUSE-T and Cryptomator run in user space. So having to reboot the Mac seems a problem of the OS as well, no?

[basepi]

Reading these threads made me want to give FUSE-T another try. So I mounted one of my vaults via FUSE-T and tried to copy some files (mp4) into it. Seconds later Finder told me that it couldn't copy the file because the source file was corrupt or something. (It's not.)

Remounted the drive with WebDav and copied the files over no problem. Obviously WebDav has its own set of problems. Have to be really careful that there are no open file handles when I try to eject or it gets stuck, as documented on many threads. But it's usable.

But back to the FUSE-T case: From prior experience, after receiving an error like that, if I were to try again, finder would just hang on "preparing files for copy". If I tried to cancel that copy, it would just hang on "cancelling". At which point I'd be stuck until a reboot. Force restarting Finder in this state results in Finder stopping, but not being able to start again. And without Finder, the mac is unusable and needs a reboot.

In fact, I went to go try again with FUSE-T to capture a screenshot of the error, and even though I successfully ejected and locked the drive, when I remounted it and tried the copy again, it's now hung on "copying 4 items". So I'm going to submit this comment and go restart my mac. (Edit: it hung on restart at my wallpaper. Had to hold the power button. Not great.)

FUSE-T is completely useless to me on an M1 MacBook Pro running Ventura 13.4.

Are there known cases where the crash led to data corruption?

That is the one silver lining. So far, I haven't seen any data corruption.

[julesallen]

The changing file date on preview was obviously a deal breaker for me, my work flow is completely broken with random mod dates so I went back to kext FUSE which continues to be rock solid.

Based on that alone I don't know why it's recommend over the stable older version. Cryptomator is used by deeply technical people who can install FUSE with ease.

Sounds like a dodged a bunch of issues by switching back. Hope this all gets addressed soon.

[overheadhunter]

Issues that we are aware of range from files being inaccessible to said Finder freezes requiring a OS restart. In all cases, remounting or switching to some other volume type allowed accessing vault contents again. So while the issues are severe, there are no reports of irrecoverable data loss.

But as now mentioned multiple times, fuse-t is a quite young solution, lacking the maturity that macFUSE built up over more than a decade. If Cryptomator detects both solutions, it prefers macFUSE (if volume type is set to "automatic"), but we understand that installing kext isn't something that every user wants to do. We still hope that Apple will eventually add a proper VFS API to macOS (File Provider API can't fill this gap). And we have plans for other FS types.

After all, Cryptomator is just a library consumer as well. It can only serve the requests it gets from the VFS implementation to its best extent but so far, every solution had some limits.

Adding more alternatives (including the File Provider API, but maybe some NFS oder SMB implementation works as well) is the best we can do to offer choice for specific use cases.

[basepi]

Ah, I didn't realize you could still install macFUSE on Ventura. I will try that out instead of FUSE-T.

[basepi]

My smoke tests were all successful, macFUSE seems to be much better than FUSE-T. Based on my experience, I don't think the downloads page should be recommending FUSE-T. But perhaps my experience is an outlier.