3 ms·
Weird that there is such detailed technical information alongside this statement: > And anyway, purists might argue that the "content" of a directory doesn't c
by an1sotropy 4y ago
Weird that there is such detailed technical information alongside this statement:
> And anyway, purists might argue that the "content" of a directory doesn't change when the files it points to change; the content is merely a list of filenames and inode numbers, after all, and those stay the same, no matter what happens inside those inodes. Purists make me sad.
Or maybe Unix makes the author sad? You can’t wish the OS into doing something different with directory files when the set of contained files has not changed (but a file was modified) so that these Make troubles could be handled differently.
Am I missing something?
- deleted 4y ago[deleted]
- photon-torpedo 4y agoThe author mentions that they also wrote a backup program (bup), and for backup programs it would be very convenient if directory mtimes would get updated like this (recursively up to the root), as it would allow to skip scanning the entire filesystem for changed files (which in my experience is where backup programs spend most of their time).
- junon 4y agoI don't remember if mtime is updated on each write call or just on fopen but I could see this being a huge performance overhead, namely for applications that are FS bound. I wonder if io_uring would help the situation though since it's mainly geared toward filesystem operations.
- Doxin 4y agoNo reason a hypothetical recursive mtime needs to be atomic. The kernel could just stick it in a buffer somewhere and deal with that sort of think out-of-band and in batches. You'd probably need some filesystem journaling trickery if you want to make sure the recursive mtime always updates eventually when a file is modified.