21–30 of 36 posts
Good news is that there is work on making the i_version field available via statx in Linux: https://lore.kernel.org/linux-nfs/20220826214703.134870-1-jl... So we might have a reliable mtime alternative in Linux soon in 2022.
The title should be: “I don’t like Mtime comparison. Here’s why.” If your name is Dijkstra and it’s 1968 feel free to use the phrase “considered harmful”, otherwise use plain language.
Anti-considered-harmful consided harmful. What's wrong with the usage? It is short and concise.
apropos > Linux added an O_NOATIME !!Con 2016 - How I fixed UNIX atime! With 10 lines of code and feminism!!! By Valerie Aurora https://www.youtube.com/watch?v=fHjsdyN4UK0
Not in my experience.
This reads weird to me.
As the author points out, a directory entry (hardlink) is just a filename pointing to an inode. When you first create a file, and there is only one filename for that file, that entry is a hardlink. So in that text the first occurrence of "hardlink" should probably read "the kernel does know all the filenames of an inode".
But then it gets weird. When the author says "hardlinks are suspiciously slow on MacOS", it sounds like they're saying "accessing files is suspiciously slow on MacOS" - because accessing any file in the filesystem goes through hardlinks. All links to a file, including the first, are hardlinks.
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…
The 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).
We're currently dealing with crashes across all Qt applications using QML on NixOS [1], since Qt utilizes the binary's mtime to invalidate the cache of embedded QML resources. Since all builds have an mtime of 0 as timestamps are the biggest source of reproducibility issues [2], QML loads outdated cache objects which will then load invalid bytecode at runtime and therefore causing a crash. Our initial plan was to uti…
> 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. You normally don't see any symptoms of this except that hardlinks are suspiciously slow on MacOS. But in exchange for the slowness, the kernel actually can look up all filenames of a hardlink if it wants. I think this has something to do with Aliases and…