GNU bug report logs - #7529
Bug#605639: deal better with different filesystem timestamp resolutions

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7529 in the body.
You can then email your comments to 7529 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: jidanni <at> jidanni.org
To: submit <at> bugs.debian.org
Subject: Bug#605639: deal better with different filesystem timestamp
	resolutions
Date: Thu, 02 Dec 2010 08:41:53 +0800

X-Debbugs-cc: bug-coreutils <at> gnu.org, bug-make <at> gnu.org
Package: coreutils
Version: 8.5-1

man cp says:
`-u'
`--update'
     Do not copy a non-directory that has an existing destination with
     the same or newer modification time.  If time stamps are being
     preserved, the comparison is to the source time stamp truncated to
     the resolutions of the destination file system and of the system
     calls used to update time stamps; this avoids duplicate work if
     several `cp -pu' commands are executed with the same source and
     destination.

But it seems that isn't working too much/well,

$ touch /tmp/f
$ /bin/cp -avu /tmp/f .
`/tmp/f' -> `./f'
$ /bin/cp -avu /tmp/f .
`/tmp/f' -> `./f'
$ /bin/cp -avu /tmp/f .
`/tmp/f' -> `./f'
$ ls -l --full-time f /tmp/f
-rw-r--r-- 1 jidanni jidanni 0 2010-12-02 08:25:47.682527260 +0800 /tmp/f
-rw-r--r-- 1 jidanni jidanni 0 2010-12-02 08:25:47.000000000 +0800 f
$ mount
/dev/sda6 on /home type ext3 (rw)
tmpfs on /tmp type tmpfs (rw)

It might work great f -> /tmp/f, but not the other way around.

By the way, make(1) lacks any of this time comparison resolution
machinery at all! I'll CC them.

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: jidanni <at> jidanni.org, 605639 <at> bugs.debian.org
Cc: submit <at> bugs.debian.org, bug-gnulib <bug-gnulib <at> gnu.org>,
	bug-coreutils <at> gnu.org, bug-make <at> gnu.org
Subject: Re: bug#7529: Bug#605639: deal better with different
	filesystem	timestamp resolutions
Date: Wed, 01 Dec 2010 21:38:22 -0800

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 <eggert <at> cs.ucla.edu>
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
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7529>.
---
 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  <eggert <at> cs.ucla.edu>
+
+	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>.
+
 2010-11-30  Bruno Haible  <bruno <at> clisp.org>
 
 	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

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bug-coreutils <at> gnu.org, 605639 <at> bugs.debian.org,
	bug-gnulib <bug-gnulib <at> gnu.org>, jidanni <at> jidanni.org
Subject: Re: bug#7529: Bug#605639: deal better with different
	filesystem	timestamp resolutions
Date: 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.

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

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: bug-coreutils <at> gnu.org, 605639 <at> bugs.debian.org,
	bug-gnulib <bug-gnulib <at> gnu.org>, jidanni <at> jidanni.org
Subject: Re: bug#7529: Bug#605639: deal better with different
	filesystem	timestamp resolutions
Date: Fri, 03 Dec 2010 10:05:53 -0800

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?  :-)

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bug-coreutils <at> gnu.org, 605639 <at> bugs.debian.org,
	bug-gnulib <bug-gnulib <at> gnu.org>, jidanni <at> jidanni.org
Subject: Re: bug#7529: Bug#605639: deal better with different
	filesystem	timestamp resolutions
Date: Sat, 04 Dec 2010 18:56:07 +0100

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.