Strange dates on files created by cryptomator

I tried researching this, but everyone wanted to talk about the dates of files stored INSIDE the cryptomator vault.

I’m talking about the dates on the files that cryptomator creates for uploading. I’m seeing dates like 1/1/1980 and 12/31/1979. How and why did cryptomator create these dates? How can I synchronize the files by dates, when the dates are so untrustworthy? Do dates matter?

Thank you!

which Cryptomator Version do you use and which drive integration (WebDAV/Dokany)?
Usually the files and folder created by cryptomator have the same date as the original file.
You can test this by creating a vault and only placing a test.txt file into it.
If you look at the cryptomator file, every time you chence the test.txt, the timestamp of the encrypted file does update as well.

Are you sure that the “strange” dates do not correspond to your (unencrypted) files?
Within my research I found picture-files on my system with dates in the future. (Pic I manually modified). And also some files of 1970 (I also manually modified).

Hmm. I guess that’s possible. There’s no way to easily match unencrypted files with encrypted. I read the explainer page which talked about how encrypted files are made. But it didn’t explicitly explain timestamps. I would have thought the timestamp information was stored inside the encrypted files.

But, checking my files, there are some weird dates in the original, so it’s a plausible explanation. There are ones that clearly have the wrong time stamp (like 1980 dates on pictures of people who weren’t born yet.). I wonder how that happened?

At the moment, it seems that in order to synchronize files and not have have hundreds of unnecessary transfers, I have to have a 3601 second tolerance window. It makes me worry whether the right things will synch up.



I think this is in your case not such a problem as you might think.
Let’s go through all the possibilities:

You have a file with date 1980 on your system. You put it into you vault and start your sync client.
Option 1: there are no corresponding vault files online -> sync will start
Option 2: there are already corresponding vaults online (because you just have overwritten the file in your vault with no changes) -> the latest version is online, no sync, everything is ok.

If you modify your 1980s file, it will get a new timestamp. If you place it into your vault and replace the existing 1980-file, the corresponding vault files will get the new timestamps as well.
If you start your sync, the latest version will be pushed to your cloud storage.

So in every case you have the latest version online in your vault. It doesnt matter if the original file has a weird timestamp (as long as it gets a new one when you modify it).

What possibly could make trouble is, if your original file date is in the future. If you update that file, it will get a timestamp “older” than the former version. Im not sure if the sync client will then start updating these files.

I have this problem, too - with real problems with my backup software.

I got a lot warnings that (ex)FAT volume can only store dates from 1980 to 2099 when I backup my local HDD to an external HDD.

Die Änderungszeit von “Y:\OneDrive\X\d\AO\xxxShortenedyyy\xxxxx~f8db.ffs_tmp” kann nicht geschrieben werden.
A FAT volume can only store dates from 1980 to 2099:
write time (UTC): 01.01.1970 00:00:00 (116444736000000000)
ERROR_INVALID_PARAMETER: Falscher Parameter. [SetFileTime]