Just a note... even reading a file updates the access time, so if you reason this way then no program touching any files in the worktree will ever be idempotent... which seems to lose the utility of the concept.
Not without breaking every program under the sun. Currently, programs on Windows can assume that the file associated with a path won't change while the file is open (at least I hope so or some of my code is a bit racy...).
> This is an easy one. Touch is by default idempotent. This means you can call it multiple times without any issues. A second call won’t have any effects
Every call to touch will alter the modification time of the file (example.txt in this case).
maybe, depending on your definition of idempotent. It does update the modification time of the file, which does result in a different state if it is run multiple times. Although in practice, that probably doesn't matter most of the time.
It seems odd that the problem is in the access time of the files - why does a font library (or, almost any program) care about the last read time of a file? Sure, the modification time is important, but it's pretty rare that code should care about when a file has been read before. The only program I have heard of that broke when access times are unreliable was mutt, the email client.
I completely disagree. A program or function is designed to perform an operation. If that operation requires the contents of the file, then the program cannot continue unless it successfully reads the contents of the file. There is already a natural asymmetry. If you cannot open the file, there isn't any more to do.
Doesn't this assume that your program can reliably access it's own source-code? Can it? It can of course read some file containing some source-code. But assume it accesses some file which contains the source-code of some other program, then wouldn't your logic still hold the same, since from the point of your program it is simply reading some file?
If you rm a file that someone else is reading, they can happily keep reading it for as long as they like. It's only when they close the file that the data becomes unavailable.
It only needs to compare actual file contents if the file properties (dates, size, ownership, rights) have altered with the options used in this example so it would only need to perform directory reads in the case of no such changes. Of course for a very large project this could still be significant, but much less so.
This isn't true at all depending on your work. I program software that has to work alongside other programs on busy file systems...failing to read/write a file is not someone else's problem...it needs to be handled, logged, there is potentially a retry and/or notification.
No it's not on the same level, it's subtly different. The file could be altered during the brief instant between when you execute the file and when the program loads itself. Or the whole thing could be run from the REPL with no "file" at all.
If the file is opened read-only, then programs should fall back to save as. Unfourtuantly, the only standard way to signal read-only is with file permisions. This will work, but many programs would likely have report a permisions error prior to the save as. Also it will cause problems for programs that transparently modify the file on disk while viewing.
I suppose you could hard code the read only parameter into the command that is used to execute the external program. Or have the external programs check if they are in a tmp-directory.
reply