Timestamp of deleted files (.stversions)

There are two files:

FileA.jpg (mod.time 20190425-180126)  
FileB.jpg (mod.time 20190513-133410)

Then they are deleted on 20190608-133605 by remote device and moved to .stversions (staggered versioning) on local device. But something has changed

before it was

FileA~20190608-133605.jpg (mod.time 20190425-180126)
FileB~20190608-133605.jpg (mod.time 20190513-133410)

now it is

FileA~20190425-180126.jpg (mod.time 20190608-133605)
FileB~20190513-133410.jpg (mod.time 20190608-133605)

It is more work now to restore from .stversions folder. Before you could search for e.g. *20190607* to find all files deleted yesterday and then just remove the “~2019xxxx” part, now you need a tool (or script) to restore the files with correct original timestamps.
Why was this changed?

It was inconsistent between versioners (some did it one way others did it the other way). The cleanout routines check mtime of the files, which now correctly tracks when the file was archived, not when it was last modified before archiving, which in some cases would immediately delete the archived files.

One could argue that the location of the timestamps should be swapped around I guess, and that the cleanout routines should be rewritten to look at the timestamp in the filenames, but what about our unloved bastard trashcan versioner that does not put timestamps in the names in general…

Also, I think the restoration UI filters based on timestamp, so you can just use that.

OK, thanks for info! I don’t use the GUI for restoration (although it is excellent feature!). I only noticed this change because I checked .stversions after I saw this bug today

Versioning setting: 60 days, staggered
File: mod.time 2017-05-20
deleted today, never made it into .stversions

Actually, this change introduced a bug, as staggered cleaning looks at the wrong timestamp. Can you raise an issue?

1 Like

Absolutely. One can also argue successfully for the the way you made it now. In the end if seems like an arbitrary decision, and I think we should stick with what you did now - original mtime in the name, delete time as the mtime.

I love that little bastard, for that specific reason. :slight_smile: If you do switch the times back, apart from the extra confusion of the double switch this will need to be different on the trashcan versioner.

There is a counter argument here, you can’t archive files with the same mtime more than once, potentially leading to data loss?

1 Like

Mmm. Regardless of the outcome the end result after multiple switches will be confusing (and mixed within any given versions dir) so we should document the decided behavior somewhere, clearly, to be able to point at.