Files and folders disappear (but still exist!) if the path name exceeds a certain length under WebDAV.
The files will show up again, if the path name is shortened (e.g. by shortening one of the parent folder names).
The files will also show up if the drive is mounted using Dokany.
When does it occur:
Main cause is when files or folders are copied or moved into too long folder paths - the data seems to completely disappear (but actually is still there).
Other cause is renaming parent folder names resulting in exceeding path length in sub folders.
This is a serious problem for two (obvious?) reasons:
we cannot find the files
we may accidentally delete files when deleting seemingly empty folders that actually contain invisible data.
Other related issues:
when trying to modify file names exceeding the maximum we receive errors pretending the file does not exist
trouble deleting folders containing hidden data without explanation as to reason (actually a good thing but confusing as there is no prompt why the deletion failed)
supposedly “missing files” reported in this forum may be a result of this bug.
It is hard to figure our what the exact path length is, but is is somewhere around 248 including the Cryptomator drive name.
The location of the encrypted files (i.e. the path length of the folder the encrypted files reside in) does not seem to be relevant with regards to this issue.
Currently using version 1.4.7 but the problem has occurred in earlier versions too.
System is Windows 10 x64 1803 Enterprise
I played around for some reproduction attempts. (on windows 10 pro 1809)
Here are some more information, maybe that helps also:
With webdav it turns out that windows is complaining at the moment when the path (only folders) length is 240. A folder structure with 240 digits will not allow to create any files, or copy of anything to a local place. (you have to delete 2 digits to copy the path to a local drive)
On Dokany, it’s a similar, but not “consistent” behavior. It allows to create 248 paths in the vault, but if you want to copy something out of the vault (or into it), you have to go down to 224 digits. I also noticed, that if you want to copy a (too long) path out of the vault a part of the folders is copied to a local storage when the error message appears. (On Webdav nothing is copied if the path is too long).
But in any case I got a message that the path is too long. I did not get the message that a file would not exist
And If I want to create that long path names at a local storage area, I receive the same message and experience the same behavior as on a webdav vault. So In my case I was not able to even create a file with that long path on my local drive, or directly in a vault.
I could imagine that there be a compatibility issue if you create and feed your vault on environments that allow file paths with more than 240 digits, and then try to open the vault on a windows machine that does not allow such long path names.
Anyway, I wasn’t gonna be able to create files in long paths on the “local environment”, or directly in the vault without windows warning me that the path is too long.
So for me it feels like a “windows vs linux vs mac” thing.
open cryptomator, click the gear symbol below the list of available drives chose “Docany” or “WebDAV” (applies to v. 1.4.9). I suppose all drives have to be unmounted first to effectively change the mode but I haven’t tried.
I have seen several threads on issues with long file paths and deep folders, but none seemed to quite match my case. Hence, I’ve decided to open a new case for this.
My issue is that when I save my (often quite long) Word files in (often quite deep) folders, a few odd things happen:
Going into the vault through the Windows explorer, I don’t see certain files with long file names that are rather deep.
Going into the vault through MS Word’s explorer, I see those files, but only when Word opens the file path as “http://cryptomator-vault:…” rather than “D:…”
Going into the vault through the Windows explorer, using the http path, I don’t see those files.
The issue may have to do with the length of file names and/or the depth of folders, since saving files through MS Word on the http path and “D:” makes them visible in Windows explorer when the path is shorter.
On the other hand, the issue does not only seem to be related to file/path length because when I use MS Word to save a file X of relatively short length in a deep folder where longer files are already shown in the Windows explorer but some issues with longer files exist, then that file X does not show up in the folder either, even though other files show up whose names are actually longer…
The bottom line here is that all files are (fortunately) somehow saved, but unfortunately not visible in Windows explorer, which makes working with them tricky, of course. Right now, I always have to go through the MS Word explorer to work on certain documents, rather than being able to access them conveniently through the Windows explorer.
I’m not sure if this was a sufficiently clear explanation for the problem, allowing you to reproduce it. Please let me know if you have any questions.
This is a problem of the Windows Explorer and its webdav client.
A workaround would be to use Dokany instead of WebDAV (can be switched in the general preferences, virtual volume tab, but only if Dokany is installed). When you use the url instead of the drive letter in the Office explorer, you circumvent this problem by not using the Windows Explorer integration.
Like you said, all files will be created and are there (you can even specifically address them via the console), but not accessable with the Explorer.
Another workaround would be by using an alternative webdav client.
Thanks a lot for everything - for the response speed, for moving my post to the right thread, and for providing this simple solution. You guys are great!