Keep modification date and other dates of original file

[tobihagemann]

Not sure if this is possible, but it would be great if the modification date and other dates of the original file can be kept after initial encryption. On the one hand it's just nice-to-have, because original metadata don't get lost. On the other hand it would then be compatible with synchronisation applications (like rsync), because they rely on the modification date.

I know this might have implications on the security, because some metadata would be revealed, but it would increase compatibility and preserve original metadata.

[tobihagemann]

Just tested this with a regular WebDAV drive. It seems to me that this is a behavior by Finder on OS X that it doesn't preserve the original dates. This probably can only be solved with an alternative frontend like FUSE as discussed in #206.

[Intuitivi]

Hello, I have the same issue. All the dates are reset to the current date once copied to the vault. Is there any workaround for it? Thanks in advance!

[daniel-steinmueller]

I'm currently testing cryptomator within a small team.
I've noticed that file modification dates are also changing once a file is just moved from one directory to another. Knowing the original date of a file is essential for us while working on different projects. (system: OSX 10.11.6 / cryptomator 1.2)

It would be great if the original modification date of each file would be preserved and just changed once a file was modified.

[aschei]

Same problem here on ubuntu 16.04 using Nautilus. Any comment how we can work around it?

[overheadhunter]

Currently we rely on the WebDAV client (i.e. the system-provided mount) to make PROPPATCH requests to set the correct file times. This will change, once we switch to FUSE (Issue #252).

[Didix57]

Same problem in Windows 7.
I would like to replace Veracrypt with Cryptomator.
I also use HLBU and PureSync. These and some other image-management tools rely on CreateDate and ModificationDate.
I really like the idea of Cryptomator.
However, I will not be able to use it with that flaw.

Actually, for the moment I do not even use a cloud space, just a HDD connected by USB or SATA.
So a network protocol would not be used at all.

[tobihagemann]

Is that so? Always thought that Windows wasn't affected by this, because Windows Explorer is doing a PROPPATCH. Could be wrong though, but yeah for Windows we'll switch to Dokany (Issue #207).

[Didix57]

It is! HLBU refused to work with an error message. Then I copied a file manually to the target directory (on my HDD) and compared the dates with the source. All three date properties of the taget were equal to Now().

I had a look at Issue #207/Dokany. When do you think will that release be ready?

Did I get this right? Cryptomator on Dokany would support HardLinks, too?
That would be fantastic since HLBU preferably works with HardLinks (as the name says :-)

[markuskreusch]

@Didix57 We currently do not know exactly when #207 will be ready.

Hard- and softlinks are not planned to be supported for now. If it is easy to do and some users really need this we may think about it.

[Didix57]

Just for my understanding ...

I would expect that a lot of tools are relying on those date attributes (at least all I use).
Therefore not supporting date attributes would drastically reduce the number of users (my guess, based on all the people I know who use the same tools).
Or do I get something wrong?
What tools do you expect (or recommend) that will be used in conjunction with Cryptomator?
And how do these handle questions/problems that are normally resolved by comparing date attributes?

Thanx for supporting!

[tobihagemann]

Wait what? The current situation is that WebDAV clients tend to not set the modification dates properly, which is out of Cryptomator's control. That's why we're hoping to fix this particular issue, when the FUSE/Dokany integration is finished. Of course, we'd like to support date attributes then. Hard and soft links are just something that we'll have to see in the future, but that's not what this issue is about. 😄

[Didix57]

Sorry, my fault - I mixed things up %-) (although I am not drunk :-)

Anyhow, what backup software would you recommend as a replacement for HLBU?
(in conjunction with Cryptometer)

[tobihagemann]

Unfortunately, I don't have any recommendation. I haven't looked into backup softwares in detail yet, but I'm also a Mac guy, so I'm really the wrong one to ask for Windows advice/tools. 😅

[ephraimfabian]

@Didix57, sorry if i'm late, I just found out about Cryptomator yesterday. I use SyncBackFree for my backup. I recommend using it for the initial encryption because it actually retains the modified date of my files. This was an issue for me before when I just copy/pasted the files or even used Teracopy.

[aschei]

Checked with 1.4.0-beta1 under Ubuntu 16.04, but modification date is NOT preserved. I created a new vault and mounted it using fuse. Then copied an old file using "cp -a " or "cp -p", but nothing is preserved, no ownership, no timestamps, no permissions.
Also: calling chown, chgrp or chmod on files within vault has no effect and is silently ignored (exit code 0). I saw some errors and warnings in the attached cryptomator.log

[overheadhunter]

chown is not supported, as the files always belong to the owner of the fuse process. We could add support to override this, using the -ouid= and -ogid= flags.

For chmod support we need to think about how to integrate it properly. For example we can not allow to remove owner read and execute permissions from directories.

But both are a different topic. This issue is about creation/modification/access times, only.

[arngast]

Isn't #323 a duplicate of this? I've tested 1.4.0 beta 2 on Suse Leap 15 and the issue still persists. I'm happy to help out.

Right now, backing anything up by syncing into the vault with rsync is useless without correct time stamps.

[StanoRiga]

I tested this on Windows 10 with Cryptomator 1.4.0 Beta 2 with Dokany.
Problem still exists. Every Time I just open the file explorer and goto to file directory, every file in it receives a new modification date. The modification date of folders seems to be untouched.
I tested also with FUSE. There the modification date is also not touched. Problem seems solved in this configuration.

[infeo]

Good news to everybody: we just fixed the Timestamp-Problem in https://github.com/cryptomator/cryptofs and thus these changes will be included in 1.4.0 version!

[infeo]

Fixed with e08c2b7 .

[tobihagemann]

Please retest with 1.4.0-beta3.

[arngast]

Works as intended on OpenSuse Leap 15. Well done and THANKS!

[aschei]

Agreed on Ubuntu 16.04 / Mint 18.3. Modification date is preserved, while ownership and permissions are not. Nevertheless: Very important FIX!

[StanoRiga]

Tested on Windows10 with Dokany and WebDav and can confirm that the timestamp is untouched now.
Unfortunately, Dokany is painful slow now.
My backup now takes 20 minutes instead of 3 minutes. I can also see a significant delay in accessing the Vault with File Explorer every time I enter a folder
(just for your information)

[lassomagic]

Seems this issue is still not fully fixed on Cryptomator 1.4.10. On MacOS Mojave 10.14.4, I copy an existing file into the vault. The modification date on the file remains the same. However the created date is new - it is the date the file is copied into the vault. I am using FUSE.

Is it possible to maintain the same created date on the file as well?

[overheadhunter]

@lassomagic You're right, this is a regression: See #867. We found the cause and will fix it in 1.4.11. You can already download a pre-release version of 1.4.11 over here.

[lassomagic]

thanks @overheadhunter

[Noisefever]

This bug happens again on ExFat Devices with Win 10.

[stefandeml]

Bug is still present on MacOS BigSur.

[poppilov]

Hi, please could you help as the problem is still happening in macOS Big Sur 11.4 as the above comment has also mentioned. Do you know if this will be given some help to? Thanks so much

[overheadhunter]

@stefandeml @poppilov Please create a new bug report, as the original bug has been fixed and the fix was confirmed multiple times. Therefore we need more information, if you're affected again.

[fabiosoft]

Still same issue for me too...
For example if a drag a drop a text file created in 2015, after locking and unlocking the vault the same file has the current timestamp date as creation date.
No more hint to original 2015 creation time.

I think i'll stop using it if i risk to loose my data.

[infeo]

@UmbraVerkisto As already suggested, please search our issue tracker for any open tickets regardung this and if none exists, open new ticket(s) (at best for each adapter a new one).

Also note that, for the combination of MacOS+WebDAV the problem cannot be solved on our side, see #220 (comment)