[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#7529: Bug#605639: deal better with different filesystem timestam
Re: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions
Fri, 03 Dec 2010 11:03:28 +0100
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.
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
> 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)