On 2023-09-19 09:31, Jeff Layton wrote:
The typical case for make
timestamp comparisons is comparing source files vs. a build target. If
those are being written nearly simultaneously, then that could be an
issue, but is that a typical behavior?
I vaguely remember running into problems with 'make' a while ago
(perhaps with a BSDish system) when filesystem timestamps were
arbitrarily truncated in some cases but not others. These files would
look older than they really were, so 'make' would think they were
up-to-date when they weren't, and 'make' would omit actions that it
should have done, thus screwing up the build.
File timestamps can be close together with 'make -j' on fast hosts.
Sometimes a shell script (or 'make' itself) will run 'make', then modify
a file F, then immediately run 'make' again; the latter 'make' won't
work if F's timestamp is mistakenly older than targets that depend on it.
Although 'make'-like apps are the biggest canaries in this coal mine,
the issue also affects 'find -newer' (as Bruno mentioned), 'rsync -u',
'mv -u', 'tar -u', Emacs file-newer-than-file-p, and surely many other
places. For example, any app that creates a timestamp file, then backs
up all files newer than that file, would be at risk.
I wonder if it would be feasible to just advance the coarse-grained
current_time whenever we end up updating a ctime with a fine-grained
timestamp?
Wouldn't this need to be done globally, that is, not just on a per-file
or per-filesystem basis? If so, I don't see how we'd avoid locking
performance issues.
PS. Although I'm no expert in the Linux inode code I hope you don't mind
my asking a question about this part of inode_set_ctime_current:
/*
* If we've recently updated with a fine-grained timestamp,
* then the coarse-grained one may still be earlier than the
* existing ctime. Just keep the existing value if so.
*/
ctime.tv_sec = inode->__i_ctime.tv_sec;
if (timespec64_compare(&ctime, &now) > 0)
return ctime;
Suppose root used clock_settime to set the clock backwards. Won't this
code incorrectly refuse to update the file's timestamp afterwards? That
is, shouldn't the last line be "goto fine_grained;" rather than "return
ctime;", with the comment changed from "keep the existing value" to "use
a fine-grained value"?
