Paul Eggert wrote: > Good eye! Thanks for the bug report and example. I installed > the following one-byte patch into gnulib; please give it a try. > It should propagate into coreutils the next time coreutils > updates from gnulib. > > A test case for this would require two file systems, one with > finer-grained time stamps than the other, where we can create > files in the latter. I suspect this goes beyond what coreutils's > test cases can easily do.
Hi Paul, Thanks for the speedy patch! Would you mind adding a "Bug fixes" entry for this in coreutils' NEWS file? It'd be nice to commit that along with an update of the gnulib submodule to the latest. As for a test, it shouldn't be too hard to create a root-only test on linux/gnu systems, since _PC_TIMESTAMP_RESOLUTION is not defined. Create two loop-mounted file systems of types that have the desired difference in time stamp resolution, and run commands like Dan did. > Subject: [PATCH] utimecmp: fine-grained src to nearby coarse-grained dest > > * lib/utimecmp.c (utimecmp): When UTIMECMP_TRUNCATE_SOURCE is set, > and the source is on a file system with higher-resolution time > stamps, than the destination, and _PC_TIMESTAMP_RESOLUTION does > not work, and the time stamps are close together, the algorithm to > determine the exact resolution from the read-back mtime was buggy: > it had a "!=" where it should have had an "==". This bug has been > in the code ever since it was introduced to gnulib. > Problem reported by Dan Jacobson in > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7529>. ... > diff --git a/lib/utimecmp.c b/lib/utimecmp.c > index 63a0c9a..8c3ca65 100644 > --- a/lib/utimecmp.c > +++ b/lib/utimecmp.c > @@ -325,7 +325,7 @@ utimecmp (char const *dst_name, > > res = SYSCALL_RESOLUTION; > > - for (a /= res; a % 10 != 0; a /= 10) > + for (a /= res; a % 10 == 0; a /= 10) > { > if (res == BILLION) > {