[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#7529: Bug#605639: deal better with different filesystem timestam
From: |
Paul Eggert |
Subject: |
Re: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions |
Date: |
Wed, 01 Dec 2010 21:38:22 -0800 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 |
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 <address@hidden>
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 <address@hidden>
+
+ 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 <address@hidden>
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
- Re: bug#7529: Bug#605639: deal better with different filesystem timestamp resolutions,
Paul Eggert <=