File moves and renames lose file modified dates

[thedewi]

Environment

• Windows version: Microsoft Windows [Version 10.0.10586]
• Processor architecture: amd64
• Encfs4win version: v1.10.1-RC10
• Dokan version (legacy, modern): modern
• Configuration: new volume created via gui, paranoia mode with default settings (nameio/block with maj/min 4/0 and chainedNameIV of 1)

Description

File moves/renames within a volume cause the date modified to be reset to the current time. Files moved in from outside the volume work correctly, presumably because the copying program writes a new file and sets properties explicitly.

Speculated cause: It looks like filenames affect file content ciphertext in this configuration (paranoia mode defaults), which means that a rename/move within a volume cannot be reflected in the outer volume as an atomic rename/move alone, because the ciphertext needs to be entirely rewritten. I expect this write is bumping the date in the outer filesystem which is then reflected in the inner volume.

I'm not sure what APIs to use, but a web browser downloading a file creates it with a date in the past, as do file managers copying from external filesystems. I think external sync or backup processes will still pick up the change correctly because the filename is new. Perhaps a new file structure should always be created too, for more certainty (which may be happening already).

I suppose it could be argued that the current behaviour has some marginal obfuscatory security value, but encfs supports ordinary modified date behaviour in other instances (I can copy files out and back in just fine) so I think preservation of the metadata would be preferable in this case too.

Expected behavior vs. actual behavior

• Expected: internal renames/moves should preserve the modified date
• Actual: internal renames/moves reset the modified date to now

Steps to reproduce problem

1. Locate (or copy in from outside) a file with a modified date in the past.
2. Using explorer or the windows command prompt: Rename the file, or move internally to a different folder.
3. Check the date modified. The modified date shows the moment of the rename/move operation, and the original date is lost.

[jetwhiz]

Hi @thedewi -- thank you for the report!

This is probably related to the fact that our unix::rename function removes the readonly and system attributes from files before moving them (and then puts them back after).

This was done to prevent directory deletes/moves/renames from failing due to the system file DESKTOP.ini that Windows Explorer adds to folders. I will see if we can reset the modified date as well so it does not get changed.

[jetwhiz]

I don't seem to be able to reproduce this issue on my end -- can you confirm the issue still exists for RC12?

[jetwhiz]

My mistake, I was running in standard mode. I can confirm this for paranoia mode.

It looks like this is caused by "External IV Chaining", which stores a per-file IV in the header of the encrypted file. As per the encfs manpage under 'External IV Chaining':

Also, renaming a file requires modifying the file header. So renames will only be allowed when the user has write access to the file.

As a result, every time a file is renamed, its underlying encrypted file is modified (to update the IV in the header), which updates its last modified date.

The only way to alleviate this issue might be to change the lastmodified timestamp back to its original value after a rename, but this might have some unintended consequences (since we would have to open the file and create a filehandle in order to retrieve the lastmodified timestamp both before and after renames). This might add considerable overhead to file move/renames.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.