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…
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
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. 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.
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.
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.