When I copy files into a Cryptomator vault, the original file metadata for “date modified” are preserved, but the “date created” metadata in the vault give the timestamp of file creation in the vault, rather than the original “date created” metadata.
I’m aware that this is how Windows normally behaves even when copying files normally on the same hard drive. However, in Windows there is a workaround using the robocopy command line utility. I’m able to use robocopy to successfully preserve “date created” metadata in copied files on my local hard drive. However, when I use it to copy files into the Cryptomator vault, the “date created” metadata still lists the timestamp for file creation in the vault rather than the original creation date.
Windows will also preserve “date created” metadata if you cut and paste the files rather than copying them. I tried cutting and pasting into my Cryptomator vault but that didn’t work either.
I’m also aware that this issue has come up in the past in different circumstances (e.g. here) but it’s not clear that these old discussions apply to my current issue. It appears another user reported the same behavior as me in this thread from over a year ago, but that thread never received any responses.
I’m on Windows 10 using Cryptomator 1.17.1 and WinFsp (Local Drive) mount type.
Same problem here. Using Windows 11 23H2 and Cryptomator 1.17.1.
I had the exact same issue ever since I downloaded Cryptomator about a year ago. So for me this occured also with older Versions of Cryptomator. Tried all of the mounts. Tried moving (not copying) files using drag and drop as well as robocopy. Tried Test Vaults on OneDrive as well as TestVaults on my Local Drive. Tried another PC (Windows 11, 22H2). Always the same issue: Date created is altered, date modified remains the same.
Any ideas as to why this issue exists for some but not for others?
This comment made me think that the date created being changed to the time of moving it into the vault might actually be the expected behavior, as the file is changing the filesystem (as the virtual drive with the decrypted files always has a different drive letter to the one from where the original file came from)?
I’m not an expert, but maybe someone can confirm this? If so I’d still be wondering why many people don’t have their date created changed.
I’ve confirmed with a test vault that if I use the WebDAV (Windows Explorer) drive type, files copied into the drive with the appropriate setting on robocopy indeed preserve the file created metadata. Furthermore, I can then change the drive type to WinFSP (Local Drive) and use it normally. So it seems like this might be a workaround for a one-time initial mass copy of files to my Cryptomator vault.
Questions:
The general sense I get from searching around is that FUSE is in general preferable to WebDAV due to the limitations mentioned on Volume Types | Cryptomator Documentation. Aside from not being able to transfer files over 4 GB and the incorrect listing for drive space, is there any disadvantage to using WebDAV?
Is it OK to do an initial mass copy of files to a drive in WebDAV format (to preserve date created metadata), and then switch the drive type to FUSE thereafter? Is it possible that any complications might arise down the line from doing so?
Thanks for the hint! After running some tests, for me this seems to be the solution for a one-time initial mass copy. Changing to WinFSP afterwards didn’t change the date created, which is great.
I initially had some problems using robocopy with the WebDAV drive, where robocopy wouldn’t recognize the vault. It finally worked when I used the network path of the drive like:
\127.0.0.1@42427\493pWmmOxK-F\TestVault\
instead of:
“E:\” or “\\cryptomator-vault@42427\493pWmmOxK-F\TestVault”
Also for some reason copying single files led to the same error, whereas copying full directories did work.
After finally getting around to implementing this, my heart skipped a beat as I found that even when copying to a WebDAV mounted drive with robocopy, files now still had the copy date as Date Created! But it turns out this only happened for some files, and only when I inspected file metadata by right clicking on the file and selecting Properties from the context menu. For other files, Date Created displayed as the original file creation date in Properties. For all files, Date Created corresponded to the original file creation date when accessed by selected Date Created as a column in the Details view of Windows Explorer. When Date Created initially displayed the copy date in Properties, it would sometimes (not always) revert to the original file created date after locking the vault and reopening in WinFSP. I’m not sure but I think this behavior might have been partially triggered by doing the initial inspection of file Properties while still in WebDAV.
No idea what to make of all that, but I assume it’s a Properties display quirk of some sort since everything was displaying properly in the Details view of Windows Explorer.
re: robocopy, I find it’s also useful to include /dcopy:DAT to preserve metadata for folders, and /MT to use multithreading for faster copying of numerous files. So e.g. robocopy C:\dir_origin X:\dir_destination /copy:DAT /dcopy:DAT /MT.