Without knowing any technical details, I’d like to ask whether it is absolutely necessary to update the file’s mtime when sending it to Trash Can.
The reason is that in many cases mtime carries very important information on the file, e.g. when dealing with very old files it’s good to know that the file was created 20 years ago and not just today, or if you have multiple files carrying the same name, mtime helps distinguish between them. With the current implementation, the original mtime seems to be lost forever. Is this correct?
Wouldn’t it be better to use atime instead of mtime when sending files to Trash Can, and then use that for cleanup? I understand that one possible problem with atime is that accessing data in .stversions directly may cause it to change, yet I still think it could be a valid approach allowing to preserve all important information on the files (since people normally don’t care about atime, but they do care about mtime).
For the record, Windows updates only atime when sending files to the system’s Recycle Bin, leaving everything else untouched.
For one, stupid filesystems don’t have atime, but perhaps we could fallback somehow.
(Also not sure how this works on Android where we can’t set mtimes to begin with. Does our mtimefs take care of it, or does expiring just not work properly there?)
I have tested Android just now. The tests were done using both my self-compiled CLI binary, and also the official app. There was no difference between the two. Also, Syncthing was run as a normal user, and not as root.
The folder was located on /sdcard in both cases. The file’s mtime was updated upon moving to .stversions.