Bug#605639: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions
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 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)
{
--
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
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
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 egg...@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 egg...@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 br...@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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
