31
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. 🫠
I don't think, inotify works for me, because I don't have a continuously running process. My users rather just run some
buildcommand and then I go and check, if any input files changed since the last run.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.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 whatcargodoes).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.