ich habe von Boxcryptor auf Cryptomator umgestellt, alles läuft rund! (Ich nutze Windows-Client 1.6.15 mit dem mitgelieferten winFSP und FUSE in Verbindung mit pcloud).
Eine Kleinigkeit die mir aufgefallen ist: Direkt nach dem öffnen des Tresors finde ich im Papierkorb von pcloud Dateien wie “write-access123[…]”, ich ordne diese dem cryptomator client zu, da ich bis dahin mit keiner anderen Anwendung Dateien geöffnet habe. Ich halte das für unkritisch, da das Anlegen von temporären Dateien hier und da vorkommt und der pcloud-sync zwischen nützlichen und temporären Dateien nicht unterscheiden kann. Dennoch die Frage: Gibt es irgendwo eine Dokumentation wann genau welche temporären Dateien von der Software erzeugt werden? (Ich hatte auch ein Verzeichnis oder Datei mit dem Namen “aaaaaaaaaaaaaaaa” im Papierkorb, das gab es auch erst seit der Umstellung auf Cryptomator, ist bisher aber nur einmal vorgekommen, regelmäßig entstehen aber dieses write-access123… Dateien.
I switched from Boxcryptor to Cryptomator, everything is running fine! (I use Windows client 1.6.15 with the included winFSP and FUSE in connection with pcloud).
A little thing I noticed: Immediately after opening the vault, I find files like “write-access123[…]” in the pcloud recycle bin, I assign them to the cryptomator client, since I hadn’t opened any files with any other application until then. I don’t think this is critical, since creating temporary files happens here and there and pcloud-sync cannot distinguish between useful and temporary files. Nevertheless, the question: Is there a documentation somewhere when exactly which temporary files are created by the software? (I also had a directory or file with the name “aaaaaaaaaaaaaaaa” in the recycle bin, which has only existed since the switch to Cryptomator, but has only happened once so far, but these write-access123… files occur regularly.
Addendum: write-access… is a temporary directory, which is created as a subdirectory of “c” in the vault. It seems to be there only for a short time after starting the Windows software.
Thank you for the addendum, subdirectory of “c” was the clue that I needed. It stands for “capability” and is part of our FileSystemCapabilityChecker. It basically checks if long filenames and long file paths are supported on the underlying file system via trial & error. And it probably does more. @infeo Maybe you know more technical details? I always thought that this only happens once with a “new” vault but maybe the feature set was enhanced?
As far as I can see, “c” is created (and deleted) every time the vault is unlocked. But it’s good that you confirm that cryptomator actually does something like this, then this is normal behavior.
For every vault it happens once. If, for some reason, the Cryptomator settings cannot be changed, then Cryptomator will try it again during the next unlock. Also, if the settings file is corrupted, it will be reset, meaning that the limit has to be deteremined again.
@Rainer If you navigate to %APPDATA%/Cryptomator/settings.json, does for every vault “section” the entry "maxCleartextFilenameLength": 12...someNumber..89, exist?
@tobihagemann just pointed out to me, that probably Cryptomator tests for write access on every unlock (and if storage is read-only, adjust the virtual filesystem). I looked into the code, yeah that is the case.
To conclude:
Cryptomator creates on every successful unlock a temporary directory called write-accessXXX and deletes it afterwards.
And when opening a vault for the first time, an additional temporary directory “aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa” with 9 subdirectories, then when opening repeatedly as described only the temporary write-accessXXX (each below “c”). Thanks infeo and tobihagemann for the quick response to my question.
It stands for “capability” and is part of our