Due to using a network volume for Cryptomator, it seems like OSX is creating a lot of ._* files that when using a cloud drive sync sort of feature, clutters my vaults and cloud drives. I have a lot of files so it create a big necessary overhead of file syncing.
There is a way to stop DS_Store files from being created ie:
But I can’t find something for the other dot underscore files. It appears it’s due to HFS and or OSX filesystems and the way it safeguards “resource forks”. In any case this is a bit obnoxious and while not directly related to Cryptomator, it is related due to how Cryptomator is designed using FUSE/WebDav filesystems that invoke this behavior from OSX.
Have others run into this? Is there some fix for this?
Sidenote: I can use a OSX tool called “dot_clean” in cron if/when these files are created they get deleted, but then I have to ensure the sync to cloud deletes the right files and it’s a bit of a pain because I need to deal with it, instead of not having to think about it at all.
A better solution from using Cryptomator’s perspective would be to have the FS that is uses interact with OSX in a way that doesn’t invoke this dot file creation behavior. Would be great if there was a safe reliable way to have that happen.
Hi @overheadhunter Yes - the ._ files are inside the vault. When I use open some files from my decrypted vault in there and open them on my mac laptop, they seem to get created - this is verified with the WebDAV mount type. To clarify, it is not just the AppleDouble files or the DS_Store ones - these are dot files that have the same name as the file opened, but prefixed with ._{fileFoo} .
Seems to be a ResourceFork apple feature, intended for Network mounts. As per https://discussions.apple.com/thread/2114601 it mentions these files that get created on network mounts may be possible to disable it on the server side, which is why I figured it was worth a post here.
It terms of mount flags, I didn’t change anything specific, it should be the flags for WebDAV out of the box using 1.5.11 (dmg-2600.111).
Ok, understood. Well on WebDAV-based volumes, as far as I know, you can’t change this behaviour. We could block certain filenames, but decided not to interfere.
If you choose FUSE, you get a bunch of mount flags to customize how the volume behaves. One of them is aforementioned noappledouble (which is currently set by default). Eventually we want to start supporting xattr, which should make all this obsolete.
Thanks @overheadhunter - I can confirm these don’t get created with osxfuse. Out of curiosity, is there any functional difference between using WebDav and the userspace filesystem or is it just a legacy design side effect? ie, started off with WebDav and moved to FUSE over time?
Correct. WebDAV was the easiest to start with, as it is one protocol supported by all major operating systems. But this also means, that by being a common denominator, no OS-specific functions are supported, restricting us in some features. Therefore we eventually added support for FUSE (and Dokany), which should be the preferred way of mounting a file system. WebDAV is still present as a fallback, if FUSE fails.
Among others, these are known WebDAV issues:
On macOS, it warns about non-https loopback connections, despite receiving a valid SSL cert for localhost is impossible.
On ARM Macs, it crashes
On Windows, it restricts file size to 4GiB
Huge request overhead for small files
On Linux, distributions fight a war over the correct URL scheme (webdav:// vs dav://), making it impossible for us to ask the file manager to mount/reveal a volume with a single working implementation.
I’d like to refresh this 1 year old topic, as exactly this is hitting me, too. I was just switching from Boxcryptor. I’m using a Synology Drive synced folder, which contains the vaults, and having those extra files synced all the time is causing a lot of overhead but, what’s more important, also introduces a lack of usability when working remote due to limited bandwidth.
I’m not going to use macFuse again. Because it’s a kernel extension and by itself does have it’s issues and kernel modules are discouraged on macOS anyway since >2 years now with the introduction of more modern services.
What I’ve seen (from switching from Boxcryptor to Cryptomator) are actually three things:
Cryptomator is leveraging it’s own WebDAV service, which is ok, but not modern
Boxcryptor and other service providers are all switching to the FileProviderExtensions API (OneDrive, SynologyDrive, Box, …)
Cryptomator is already using the this modern API in the iOS client, but the Mac client lags behind here.
Therefore one suggestion: wouldn’t it be possible to introduce a more modern Mac client built on the same technology as the iOS client and remove all the hassles with virtual filesystems/extra WebDAV clients on the Mac?
Unfortunately, it’s not the exact same technology on macOS as on iOS (NSFileProviderReplicatedExtension vs. NSFileProviderExtension) so it wouldn’t be that easy. However, we understand that the current situation is not ideal and we’re actually working on a solution that fits conceptually with Cryptomator’s virtual drive design and also doesn’t require kernel extensions: Support for FUSE-T (macOS FUSE implementation without kext) · Issue #2482 · cryptomator/cryptomator · GitHub
This sound promising! Your effort is very much appreciated! Thanks!
One caveat so: as an end-user I really would like this to be included in the Cryptomator app directly, not as a separate download. Separate downloads of additional products (especially in a security context) always have a bad taste to me …
Yes - the