Bug#605639: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions

[Jim Meyering]

Paul Eggert wrote:

> On 12/03/10 02:03, Jim Meyering wrote:
>
>> 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.
>
> Sure, done, with this notice:
>
>   cp -u no longer does unnecessary copying merely because the source
>   has finer-grained time stamps than the destination.

Thanks!

>> 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.
>
> Hmm, well, I can see a lot going wrong with that, such as garbage in the
> mount table if the test is interrupted.  (Also, there's the little problem
> that I lack root access on the hosts that I do builds on these days: does
> that get me off the hook?  :-)

I didn't mean to make it sound like a requirement.
I was merely thinking aloud about how I might do it.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605639: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions

[Paul Eggert]

On 12/03/10 02:03, Jim Meyering wrote:

> 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.

Sure, done, with this notice:

  cp -u no longer does unnecessary copying merely because the source
  has finer-grained time stamps than the destination.

> 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.

Hmm, well, I can see a lot going wrong with that, such as garbage in the
mount table if the test is interrupted.  (Also, there's the little problem
that I lack root access on the hosts that I do builds on these days: does
that get me off the hook?  :-)




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605639: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions

[Jim Meyering]

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
> .
...
> 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)
>{



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#605639: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions

[Paul Eggert]

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.

>From 409c6b774c25afce33f8b67fbf7af3eb3304f6cf Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Wed, 1 Dec 2010 21:25:56 -0800
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
.
---
 ChangeLog  |   14 ++
 lib/utimecmp.c |2 +-
 2 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index d4eb684..67e2977 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,17 @@
+2010-12-01  Paul Eggert  
+
+   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
+   .
+
 2010-11-30  Bruno Haible  
 
strerror_r-posix: Fix autoconf test.
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)
   {
-- 
1.7.2




-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org