Mtime comparison considered harmful

In Ninja I sorta stumbled through some of the same issues described here. I eventually realized that the interesting question is "does this output file reflect the state of all the inputs" and not anything in particular about mtimes, and that"inputs" includes not only the contents of the input files, but also the executables and command lines used to produce the output. If you squint, mtime/inode etc. behave like a weak content signature of the input. And once you have…

> Random side note: on MacOS, the kernel does know all the filenames of a hardlink, because hardlinks are secretly implemented as fancy symlink-like data structures. Note that the link is outdated and refers to HFS+. HFS+ originated in classic Mac OS and originally didn't support hard links at all, so they had to be added after the fact [1] using a hacky format based on a hidden directory. APFS has a cleaner design, but it still tracks the list…

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…