$ ls --full-time z
-rw-rw-r-- 1 ncw ncw 807 2019-06-13 14:27:42.181050459 +0100 z
ncw@dogger:~$ stat z
File: z
Size: 807 Blocks: 8 IO Block: 4096 regular file
Device: fd01h/64769d Inode: 11799923 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ ncw) Gid: ( 1000/ ncw)
Access: 2019-06-26 12:53:37.336375660 +0100
Modify: 2019-06-13 14:27:42.181050459 +0100
Change: 2019-06-13 14:27:42.189050495 +0100
Birth: -
Access time you can't change, Modify time is the one ls shows normally and is the time the file changed. ctime is same as mtime except it changes if you change the access details on the file too.
So no created time...
Windows does have created time, but it is the only supported OS that does!
Thanks.
But how does the VFS cache handle this then when you set a max-age on the cache? A new modtime doesn't get set just because it copied into the cache, so how does it know how long it's been there?
I'm asking because I'm kind of trying to do something similar for a folder using an external script.
I don't recommend using them with mount as it will filter the directory listings according to age which will surely be confusing!
Perhaps you mean?
--vfs-cache-max-age duration Max age of objects in the cache. (default 1h0m0s)
In which case your question is a very good one. Rclone uses the atime of the file to know when it was put in the cache. This isn't a particularly good measure since it isn't always set properly and I have no idea how well it works on windows... Normally this doesn't matter as rclone keeps the age in memory, but if you restart rclone you can sometimes see it deleteing the entire cache...
I'd like to move to keeping this metadata in a file on disk eventually.
I guess access time works, but I AFAIK there is neither a flag or filter in rclone currently that would let me sort that way. I guess I will have to work it out some other way.
But as a sidenote on the VFS cache (even though it it off-topic) - yes it absolutely looks like it needs some kind of persistence through restarts. The access times are one thing (although I haven't noted any bad behaviour on Windows) but more importantly is that the "files tp be uploaded" list is not lost so that "moved" files don't risk being just lost in the VFS cache in the case of a crash, unexpected power-loss ect. Anything that could cause data-loss is a pretty big deal, and that definitely seems like a big potential in the VFS currently when that information isn't stored anywhere outside of the rclone instance memory.