> Annoyingly, when you update the content of a file, the mtime of its containing directory is not changed. [...] And anyway, purists might argue that the "conte

> Annoyingly, when you update the content of a file, the mtime of its containing directory is not changed. [...] 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. 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.