Mtime Comparison Considered Harmful (2018)

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 of hard links to an inode. [2]

[1] http://www.wsanchez.net/papers/USENIX_2000/

[2] https://developer.apple.com/support/downloads/Apple-File-Sys..., search for "Siblings"

It might be partly due to hardlinks, but I suspect it is mostly an efficiency issue. Modifying a file could mean updating quite a few directories every time if you have a deep tree. For some uses this could be quite a performance hit, and for some media would potentially reduce the life of your hardware too.

IIRC even when updating atime for every access was the usual default for many filesystems, only the current object had its time updated not all its chain of parents.

Production builds should be a full build.

It is customary to have various optimizations in modify/save/rebuild/execute/verify loop.

I, for one, don't even restart the app for most changes and use REPL to modify application at run time. I only rebuild it from scratch and restart from time to time to verify it all still works as intended.

Isn't POSIX fun?

All those fancy checks plus database could be added to make too if you really wanted. It still wouldn't support all the fancy features of redo, but improve your experience with all those existing projects based on make.

A point that neither this article nor the recent ninja retrospective (http://neugierig.org/software/blog/2020/05/ninja.html) touch on though is that hashing of files is an important step if you'd like to keep caches locally, but especially if you'd like to keep caches remotely.

A key reason that Bazel-alikes (including http://www.pantsbuild.org, which I work on) hash things is for use in cache keys. And many of those systems use file watching facilities (notify, fsevents) to determine whether files need to be rehashed. If done properly (i.e.: no false negatives), this is significantly faster than checking file mtimes, and it allows for "early cutoff", where if after hashing the digest of a file has not actually changed, you can skip rebuilding its dependents.

Meaning with the command:

  foo.o: foo.c
      cc -o foo.o $(CFLAGS) foo.c

Also, I was under the (mistaken?) impression that some make actions came from a dependency tree, not a timestamp. Otherwise everything would be breaking during any invocation.

One other point about ATIME -- turn it off if you value your SSD.

Does anyone have an idea what's going on there?

I don’t think it’s just about purism. For some it might be. But to me, ever since I learned some of the details about how for example the FreeBSD VFS is implemented, from reading the book The Design and Implementation of the FreeBSD Operating System by M. K. McKusick, it makes sense. Prior to that my own mental model of how file systems work on for example FreeBSD was very fuzzy. But reading about the technical details, like what kinds of structs are being used in the VFS and what fields those structs have, I realized why a lot of things are the way that they are.

In the same paragraph that I quoted above, in the part I omitted for relevance, he also said:

> All sorts of very convenient tree traversals would be possible if the directory mtime were updated (recursively to the root) when contained files changed, but no. This is probably because of hardlinks: since the kernel doesn't, in general, know all the filenames of an open file, it literally cannot update all the containing directories because it doesn't know what they are either.

On this I have two thoughts.

1. Doing this means adding more overhead every time a file is written to. The overhead might be negligible, or it might be significant. We’d have to run a lot of benchmarks to really know. (For me the answer is that with the mental model of the file system that I have as mentioned above, I don’t desire this anyways, so I am not personally even going to do that type of benchmarking.)

2. Consider that one or more directories in the path between the root and your current working directory may be mounted from a file system different from the root file system. They might not even be local to the system! For example, perhaps your home directory is mounted over NFS or SMB. That’s certainly common in a lot of deployments at universities and big companies. From a philosophical point of view, does it even make sense to modify the mtime of every directory from the root down to your current working directory when you modified a file that is being written to a storage medium that isn’t even local to your system? And from a practical point of view, what good does it do that the desktop computer on desk A in floor 2 had all of its mtimes in its path modified when you head on up to floor 3 and sit down at the computer on desk K? Any tools you have that were relying on being able to start at the root file system and scan mtimes to find modified files would end up sometimes picking up changes (because someone else had recently modified another file in their respective home directory while logged onto computer 3K) and sometimes not (because at other times no one had been changing any files in their home directories between the time that you last did so on computer 3K and when you came back to it after having worked on your files from computer 2A).

As a workaround you might say, okay so let’s stop at file system boundaries. And that might work out, but it’s a bit hairy.

And still it could be that a longer component of the remote path is sometimes mounted and sometimes a shorter component. Then again, if the remote system is also doing this recursive mtime modification then that by itself is not a problem.

Furthermore, as a consequence of this, in order to make things workable, you should also be changing mtimes of all parent directories when mounting any file system to the most recent mtime of the file system you are mounting, if it is more recent than the mtime of the directory you are mounting it on in order to make the change visible. And if that makes sense then it means that mounting and unmounting file systems are considered as a change, so actually when mounting always set the mtime of all parents to now, and when unmounting update all mtimes again.

It seems like a lot of hassle, and potentially bad for performance. Though again, measurements would need to be done. And in the end I maintain that it boils down to what your mental model is for how the file systems that you use work.

That's a much easier way to know something's changed if you're going to the trouble of keeping state.