TIL last-modified timestamp of a dir updates when a file/subdir is added/renamed/deleted
from Ephera@lemmy.ml to linux@lemmy.ml on 21 Apr 13:50
https://lemmy.ml/post/28939360

Screenshot showing how the directory last-modified timestamp changes each time a file underneath it is added, renamed and then removed.

I’m currently working on a build tool, which does caching based on the last-modified timestamp of files. And yeah, man, I was prepared for a world of pain, where I’d have to store a list of all files, so I could tell when one of them disappears.
I probably would’ve also had to make up some non-existent last-modified timestamp to try to pretend I know when that file got deleted. I figured, there’s no way to ask the deleted file when it got deleted, because it doesn’t exist anymore.

Thank you, to whomever had that smart idea to design it like that. I can just take the directory last-modified timestamp now, if it’s the highest value.
In fact, my implementation accidentally does this correct already. That’s how I found out. 🫠

#linux

threaded - newest

wildbus8979@sh.itjust.works on 21 Apr 13:56 next collapse

Regardless, even if it’s just for your own one situation, you’ll want to look at ionotify

Ephera@lemmy.ml on 21 Apr 14:05 collapse

I don’t think, inotify works for me, because I don’t have a continuously running process. My users rather just run some build command and then I go and check, if any input files changed since the last run.

notabot@lemm.ee on 21 Apr 14:44 collapse

I’m sure you’ve already considered it, but from that description it sounds very much like make. That compares the input files’ timestamps to the output files’ timestamps, so it might be different to your plan though.

Ephera@lemmy.ml on 21 Apr 15:15 collapse

Yeah, I’m building more-or-less an alternative to make. Major difference is that I’m not using shell commands, but rather users will define their build code in Rust …because it’s intended to be a build tool for Rust applications (beyond what cargo does).

Thanks for the comment, though. So far, I haven’t limited inputs to just be files, so I don’t actually assume to have a last-modified timestamp. Rather, my assumption is that I can get some value which changes when the input changes. In the case of a file, that’s the last-modified timestamp, but theoretically, it could also be a hash. But that means I have to store these values to be able to detect a change. Being able to just say that one thing is newer than the other without storing anything, that is pretty cool and might be worth changing my assumption for.

jdnewmil@lemmy.ca on 21 Apr 15:11 next collapse

It is not recursive though. A directory is a special kind of inode that enumerates file inode numbers and when that list changes then the contents of that “directory inode” change. But if /home/user/.bashrc is deleted then the timestamp for /home will not be affected because the timestamps are associated with inodes rather than directory entries (assuming no symbolic links are involved).

www.redhat.com/en/blog/inodes-linux-filesystem en.wikipedia.org/wiki/inode

Ephera@lemmy.ml on 21 Apr 16:54 collapse

Yeah, good point. It also doesn’t update when the content of a file changes. So, in order to detect a change in a directory, you have to walk all the files and sub-directories and the directory itself to get the last-modified timestamp for each of them. Then determine the highest last-modified and compare it to what you measured in a previous run. If they differ, a change happened.

RedWizard@hexbear.net on 21 Apr 15:19 collapse

I love discovering little things like this. That’s a interesting find!