Re: copyright years: mass-update every January 1
Hi All! Le 28 juil. 09 à 02:36, Joel E. Denny a écrit : diff --git a/src/head.c b/src/head.c index c96f910..89b6ef9 100644 --- a/src/head.c +++ b/src/head.c @@ -1,6 +1,5 @@ /* head -- output first part of file(s) - Copyright (C) 89, 90, 91, 1995-2006, 2008-2009 Free Software - Foundation, Inc. + Copyright (C) 89, 90, 91, 1995-2006, 2008-2009 Free Software Foundation, Inc. While at it, why not standardize everything to 4 digits (I don't think we need to address the Y10k issues yet :), and to introduce intervals where applicable? Is there some legal thingy that forbids it? It might help making some lines smaller. + Copyright (C) 1989-1991, 1995-2006, 2008-2009 Free Software Foundation, Inc.
Re: no feedback on snapshot? coreutils-7.5 coming soon
Pádraig Brady wrote:
Jim Meyering wrote:
AFAIK, I am the only one who has built the latest snapshot:
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/17604
Though it's been only two days.
Unless I hear of new bug reports or portability problems soon,
expect coreutils-7.5 to be released in the next few days.
checks pass on Fedora 11 and Ubuntu 7.10
2 failures on Fedora Core 5 due to copy::utimensat_if_possible() failing with:
$ (cd tests make check TESTS=cp/abuse VERBOSE=yes)
cp: preserving times for `c/1': No such file or directory
$ (cd tests make check TESTS=mv/part-symlink VERBOSE=yes)
mv: preserving times for `loc_reg': Too many levels of symbolic links
These highlighted a couple of issue I think on systems without utimensat().
1. The symlink _target_ gets its time updated
2. If 1 fails then the process returns a failure
I've fixed both in the attached patch hopefully
by only doing the explicit utimensat() on symlinks,
and only giving a warning if errno==ENOTSUP.
Note it might be cleaner to add a O_NOFOLLOW flag to
utimens() in gnulib, but that would be more invasive.
I also tweaked the tests not to fail on systems
without utimensat().
cheers,
Pádraig.
From d337e3c7c081e1262ea13fbe239938c451b0a93d Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Thu, 13 Aug 2009 10:39:10 +0100
Subject: [PATCH] cp, mv: fix issues with preserving timestamps of copied symlinks
* src/copy.c (copy_internal): On systems without utimensat() don't
revert to utimens as that will update the timestamp of the symlink
target. Also just warn on systems without utimensat(), don't fail.
* tests/cp/abuse: To work around a failure on systems without
utimensat(), use cp -dR rather than cp -a.
* tests/mv/part-symlink: Skip the test on systems without
utimensat(), as mv -b will warn there, messing up the test.
---
src/copy.c| 20 +++-
tests/cp/abuse|2 +-
tests/mv/part-symlink |6 ++
3 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/src/copy.c b/src/copy.c
index bed90c4..068eef7 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -118,18 +118,17 @@ static bool owner_failure_ok (struct cp_options const *x);
static char const *top_level_src_name;
static char const *top_level_dst_name;
-/* Wrap utimensat-with-AT_FDCWD and utimens, to keep these
- cpp directives out of the main code. */
+/* Try to update the timestamp of a symlink.
+ We don't revert to utimens as that will follow the link. */
static inline int
-utimensat_if_possible (char const *file, struct timespec const *timespec)
+utimens_symlink (char const *file, struct timespec const *timespec)
{
- return
#if HAVE_UTIMENSAT
-utimensat (AT_FDCWD, file, timespec, AT_SYMLINK_NOFOLLOW)
+ return utimensat (AT_FDCWD, file, timespec, AT_SYMLINK_NOFOLLOW);
#else
-utimens (file, timespec)
+ errno = ENOTSUP;
+ return -1;
#endif
-;
}
/* Perform the O(1) btrfs clone operation, if possible.
@@ -2117,10 +2116,13 @@ copy_internal (char const *src_name, char const *dst_name,
timespec[0] = get_stat_atime (src_sb);
timespec[1] = get_stat_mtime (src_sb);
- if (utimensat_if_possible (dst_name, timespec) != 0)
+ if ((dest_is_symlink
+ ? utimens_symlink (dst_name, timespec)
+ : utimens (dst_name, timespec))
+ != 0)
{
error (0, errno, _(preserving times for %s), quote (dst_name));
- if (x-require_preserve)
+ if (x-require_preserve ! (dest_is_symlink errno == ENOTSUP))
return false;
}
}
diff --git a/tests/cp/abuse b/tests/cp/abuse
index 285c531..e9086b8 100755
--- a/tests/cp/abuse
+++ b/tests/cp/abuse
@@ -37,7 +37,7 @@ for i in dangling-dest existing-dest; do
test $i = existing-dest echo i t
test $i = dangling-dest rm -f t
- cp -a a/1 b/1 c 2 out fail=1
+ cp -dR a/1 b/1 c 2 out fail=1
compare out exp || fail=1
diff --git a/tests/mv/part-symlink b/tests/mv/part-symlink
index 78da70a..576bb40 100755
--- a/tests/mv/part-symlink
+++ b/tests/mv/part-symlink
@@ -27,6 +27,12 @@ fi
cleanup_() { rm -rf $other_partition_tmpdir; }
. $abs_srcdir/other-fs-tmpdir
+# without utimensat() mv -b will give warnings about not
+# being able to preserve the timestamps of symlinks.
+# So just skip the test on older systems like this.
+grep '^#define HAVE_UTIMENSAT' $CONFIG_HEADER /dev/null ||
+ skip_test_ 'system will warn about preserving timestamps of symlinks'
+
pwd_tmp=`pwd`
# Unset CDPATH. Otherwise, output from the `cd dir' command
--
1.6.2.5
Re: dd killed with USR1 right after ftruncate()
Voelker, Bernhard wrote:
Hi *,
short question:
is there a particular reason why the signal handlers are installed after
ftruncate() in dd?
Long story:
I ran dd for a new backup of my 150GB partition to an external USB drive
while I started
while kill -USR1 pid ; do sleep 30 ; done
in a separate terminal. The target file already existed and reflected a
previous backup.
After a while, dd ended with the standard USR1 signal handler.
The only work done so far was to truncate the old output file.
So my guess was that installing the signal handler for SIGUSR1 is done after
the truncation. So I looked into the latest sources (coreutils-7.4) and found
out
that my guess was right:
if (ftruncate (STDOUT_FILENO, size) != 0)
{
snipped /
}
}
#endif
}
install_signal_handlers ();
So why does ftruncate() before install_signal_handlers()?
What is your exact dd command please, and destination file system.
I'm a bit confused as ftruncate is not called unless you specify a
non zero seek= but that seems a bit weird from your described usage.
Also I'm confused as to why a non zero seek would take a while.
On vfat I suppose, but that only supports 4G files, not 150G.
You're right though in that the signal handlers are installed
just around the copy. I need to double check if that's by design.
cheers,
Pádraig.
Re: Enhacement request - 'date' util
On Wed, 12 Aug 2009, Alejandro Redondo wrote: Well, the first clock set, when ntpd starts, is made in just one step. This can be a problem when the client host is several seconds different than the ntp server. Stepping versus slewing can be configured in ntpd. By default small time offsets are slewed, and large offsets stepped. In the example I suffered, I had to sync different flavors clients with the ntpd servers. Unluckily some of them had the ntpd daemon stopped for a lot of time and they had differences, to have an example, about 100secs (ntpdate -d ntp_serve used to know it). It was not a problem on solaris/hpux boxes to use the date -a 100.00 and then restart the ntpd daemon with the right config avoiding a 100secs jump in time. How fast does the kernel slew? A 0.5ms/s drift rate will fix 100s error in around 2.3 days; slewing is inappropriate for large corrections. If software can't tolerate backward steps in time then perhaps it's better to halt it while the system clock is fixed. (BTW, leap seconds make this hard.) These commands are better suited to altering the frequency of the system clock: ntpdate -B ntpd -g -q -x adjtimex --singleshot Cheers, Phil
AW: dd killed with USR1 right after ftruncate()
Pádraig wrote: What is your exact dd command please, and destination file system. I was running KNOPPIX 5.3.1; the source was a harddisk partition, and the target was a file in an ext2 filesystem on a harddisk in an USB device mounted on /media/sdb2/: $ dd if=/dev/sda5 of=/media/sdb2/backups/sda5 bs=1G I'm a bit confused as ftruncate is not called unless you specify a non zero seek= but that seems a bit weird from your described usage. hmm, so maybe it has not actually been the truncate() which took so long but the fd_reopen() using O_TRUNC. Have a nice day, Berny
Re: AW: dd killed with USR1 right after ftruncate()
Voelker, Bernhard wrote: Pádraig wrote: What is your exact dd command please, and destination file system. I was running KNOPPIX 5.3.1; the source was a harddisk partition, and the target was a file in an ext2 filesystem on a harddisk in an USB device mounted on /media/sdb2/: $ dd if=/dev/sda5 of=/media/sdb2/backups/sda5 bs=1G I'm a bit confused as ftruncate is not called unless you specify a non zero seek= but that seems a bit weird from your described usage. hmm, so maybe it has not actually been the truncate() which took so long but the fd_reopen() using O_TRUNC. Sounds like a good reason to defer SIGUSR1 from post-getopt/arg-verify until when the copy-timer starts.
Re: copyright years: mass-update every January 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Akim Demaille on 8/13/2009 1:59 AM: - Copyright (C) 89, 90, 91, 1995-2006, 2008-2009 Free Software - Foundation, Inc. + Copyright (C) 89, 90, 91, 1995-2006, 2008-2009 Free Software Foundation, Inc. While at it, why not standardize everything to 4 digits (I don't think we need to address the Y10k issues yet :), and to introduce intervals where applicable? Is there some legal thingy that forbids it? It might help making some lines smaller. Yes - see this post: http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00184.html I'm not personally opposed to compressed years, but if you want the tool to output compressed years instead of longhand, it should be an option (and more importantly, we should also fix the tool to allow longhand years for maintainers that want longhand). - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqEBmoACgkQ84KuGfSFAYBOiQCeL/zuVk4tSfeK2C9XgRMofxSN qL0An3rSH71mhpvvJeqwKGOs76hxvnCz =qAzZ -END PGP SIGNATURE-
Re: AW: dd killed with USR1 right after ftruncate()
Jim Meyering wrote: Voelker, Bernhard wrote: Pádraig wrote: What is your exact dd command please, and destination file system. I was running KNOPPIX 5.3.1; the source was a harddisk partition, and the target was a file in an ext2 filesystem on a harddisk in an USB device mounted on /media/sdb2/: $ dd if=/dev/sda5 of=/media/sdb2/backups/sda5 bs=1G I'm a bit confused as ftruncate is not called unless you specify a non zero seek= but that seems a bit weird from your described usage. hmm, so maybe it has not actually been the truncate() which took so long but the fd_reopen() using O_TRUNC. Sounds like a good reason to defer SIGUSR1 from post-getopt/arg-verify until when the copy-timer starts. Yep I think so. Moving just the install_signal_handlers() to the top, then when the copy starts you'll get: 0+0 records in 0+0 records out 0 bytes (0 B) copied, 3.6457e-05 s, 0.0 kB/s cheers, Pádraig. p.s. I'm still unsure as to why open(O_TRUNC) takes a while. Perhaps there is a trunc=paranoid mount option I'm unaware of that actually writes zeros when truncating a file.
AW: AW: dd killed with USR1 right after ftruncate()
Pádraig wrote: Yep I think so. Moving just the install_signal_handlers() to the top, can we expect this to happen in one of the next releases? p.s. I'm still unsure as to why open(O_TRUNC) takes a while. Perhaps there is a trunc=paranoid mount option I'm unaware of that actually writes zeros when truncating a file. I guess this depends on the filesystem type. E.g. on another Solaris10 box with UFS `dd if=/dev/zero of=$HOME/x bs=1G count=10` takes a rather good ~1.5min while the subsequent open(O_TRUNC) then takes ~6sec. I don't think zeroes are written there ;-) Thank you have a nice day, Berny
Re: AW: dd killed with USR1 right after ftruncate()
Pádraig Brady wrote: Jim Meyering wrote: Voelker, Bernhard wrote: Pádraig wrote: What is your exact dd command please, and destination file system. I was running KNOPPIX 5.3.1; the source was a harddisk partition, and the target was a file in an ext2 filesystem on a harddisk in an USB device mounted on /media/sdb2/: $ dd if=/dev/sda5 of=/media/sdb2/backups/sda5 bs=1G I'm a bit confused as ftruncate is not called unless you specify a non zero seek= but that seems a bit weird from your described usage. hmm, so maybe it has not actually been the truncate() which took so long but the fd_reopen() using O_TRUNC. Sounds like a good reason to defer SIGUSR1 from post-getopt/arg-verify until when the copy-timer starts. Yep I think so. Moving just the install_signal_handlers() to the top, then when the copy starts you'll get: 0+0 records in 0+0 records out 0 bytes (0 B) copied, 3.6457e-05 s, 0.0 kB/s cheers, Pádraig. p.s. I'm still unsure as to why open(O_TRUNC) takes a while. Truncating a large file can cause a surprising delay, due to the amount of metadata manipulation that must be performed on some file system types.
Re: AW: AW: dd killed with USR1 right after ftruncate()
Voelker, Bernhard wrote: Pádraig wrote: Yep I think so. Moving just the install_signal_handlers() to the top, can we expect this to happen in one of the next releases? p.s. I'm still unsure as to why open(O_TRUNC) takes a while. Perhaps there is a trunc=paranoid mount option I'm unaware of that actually writes zeros when truncating a file. I guess this depends on the filesystem type. E.g. on another Solaris10 box with UFS `dd if=/dev/zero of=$HOME/x bs=1G count=10` takes a rather good ~1.5min while the subsequent open(O_TRUNC) then takes ~6sec. I don't think zeroes are written there ;-) Thanks for the clarification. I guess the file systems need time to deallocate all the blocks. Right so the attached seems to address the issue and passes all tests. I don't see much problem with adding this to the release we're trying to complete this week. cheers, Pádraig. From 2e4fbc9f1da8d2041f9ea0abd65c5213954f4255 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com Date: Thu, 13 Aug 2009 14:37:43 +0100 Subject: [PATCH] dd: fix a signal handling race * src/dd.c (main): Install the signal handlers at startup rather than just before the copy starts. In this way signals received before the copy (like during a slow truncate for e.g.) will be deferred and handled consistently. * THANKS: Add Bernhard's email address. * NEWS: Mention the fix. Reported by Bernhard Voelker. --- NEWS |3 +++ THANKS |1 + src/dd.c |4 ++-- 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 6df0d65..a88546d 100644 --- a/NEWS +++ b/NEWS @@ -7,6 +7,9 @@ GNU coreutils NEWS-*- outline -*- dd's oflag=direct option now works even when the size of the input is not a multiple of e.g., 512 bytes. + dd now handles signals consistently even when they're received + before data copying has started. + install runs faster again with SELinux enabled [introduced in coreutils-7.0] diff --git a/THANKS b/THANKS index d3541ce..bd078db 100644 --- a/THANKS +++ b/THANKS @@ -75,6 +75,7 @@ Bernd Melchers melch...@cis.fu-berlin.de Bernhard Baehr bernhard.ba...@gmx.de Bernhard Gabler bernh...@uni-koblenz.de Bernhard Rosenkraenzer b...@redhat.de +Bernhard Voelkerbernhard.voel...@siemens-enterprise.com Bert Deknuydt bert.deknu...@esat.kuleuven.ac.be Bert Wesarg bert.wes...@googlemail.com Bill Peters pet...@gaffel.as.arizona.edu diff --git a/src/dd.c b/src/dd.c index d9e4c85..30bd808 100644 --- a/src/dd.c +++ b/src/dd.c @@ -1828,6 +1828,8 @@ main (int argc, char **argv) int exit_status; off_t offset; + install_signal_handlers (); + initialize_main (argc, argv); set_program_name (argv[0]); setlocale (LC_ALL, ); @@ -1928,8 +1930,6 @@ main (int argc, char **argv) } } - install_signal_handlers (); - start_time = gethrxtime (); exit_status = dd_copy (); -- 1.6.2.5
Re: AW: AW: dd killed with USR1 right after ftruncate()
Pádraig Brady wrote: Voelker, Bernhard wrote: Pádraig wrote: Yep I think so. Moving just the install_signal_handlers() to the top, can we expect this to happen in one of the next releases? p.s. I'm still unsure as to why open(O_TRUNC) takes a while. Perhaps there is a trunc=paranoid mount option I'm unaware of that actually writes zeros when truncating a file. I guess this depends on the filesystem type. E.g. on another Solaris10 box with UFS `dd if=/dev/zero of=$HOME/x bs=1G count=10` takes a rather good ~1.5min while the subsequent open(O_TRUNC) then takes ~6sec. I don't think zeroes are written there ;-) Thanks for the clarification. I guess the file systems need time to deallocate all the blocks. Right so the attached seems to address the issue and passes all tests. I don't see much problem with adding this to the release we're trying to complete this week. Thanks for doing that. I agree that is seems safe, so please push it.
Re: no feedback on snapshot? coreutils-7.5 coming soon
Pádraig Brady wrote: Pádraig Brady wrote: C de-Avillez wrote: Sorry for the delay, got busy. I just built make check, and got two errors. First one is here, I will re-run the second error by itself in a few. Running on Ubuntu 9.10 (kernel 2.6.31.5 with Ubuntu mods, libc6 2.10.1-0ubuntu6). FAIL: tail-2/pid + tail --pid=2147483647 -f /dev/null + fail=1 + timeout 1 tail -s.1 -f /dev/null --pid=2147483647 + test 1 = 124 So tail silently returns with 1 immediately. The only way I can see this happening is in tail_forever_inotify() at: if (follow_mode == Follow_descriptor !found_watchable) return; I'd better try and pay attention in this meeting ;) Meeting over :) Following from the above analysis, does the attached help? cheers, Pádraig. From af996b0e868752c633477a90802d2dcb382725b8 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com Date: Wed, 12 Aug 2009 19:01:56 +0100 Subject: [PATCH] tail: fix tail -f failure when inotify used * src/tail.c (tail_inotify_forever): Use the correct bounds in the error check of the return from inotify_add_watch(). Reported by C de-Avillez. --- src/tail.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/tail.c b/src/tail.c index 3c8f425..7d84bec 100644 --- a/src/tail.c +++ b/src/tail.c @@ -1231,7 +1231,7 @@ tail_forever_inotify (int wd, struct File_spec *f, size_t n_files, if (hash_insert (wd_table, (f[i])) == NULL) xalloc_die (); - if (follow_mode == Follow_name || f[i].wd) + if (follow_mode == Follow_name || 0 = f[i].wd) Ten lines above that, we ensure that 0 = f[i].wd is true, so this stmt: if (follow_mode == Follow_name || 0 = f[i].wd) is equivalent to this: if (follow_mode == Follow_name || true) aka, if (true) so perhaps that change should be larger: - if (follow_mode == Follow_name || f[i].wd) -found_watchable = true; + found_watchable = true; Also, the initialization (farther above) of f[i].wd to a valid file descriptor value (0) seems like a mistake: - f[i].wd = 0; + f[i].wd = -1; What do you think?
Re: no feedback on snapshot? coreutils-7.5 coming soon
Pádraig Brady wrote: While I'm at it here's a patch to improve that test. cheers, Pádraig. From c720e160a96b813a7c24c5ac8a9a9a37590f4190 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com Date: Wed, 12 Aug 2009 19:46:27 +0100 Subject: [PATCH] tests: improve one of the tail --pid tests * tests/tail-2/pid: Speed up the test by specifying a timeout of 100ms rather than the default 1s. Also instead of failing in the unlikely case were the pid required to be missing pid is present, skip the test. Looks good. Please push.
Re: no feedback on snapshot? coreutils-7.5 coming soon
Jim Meyering wrote:
Pádraig Brady wrote:
Subject: [PATCH] tail: fix tail -f failure when inotify used
* src/tail.c (tail_inotify_forever): Use the correct bounds
in the error check of the return from inotify_add_watch().
Reported by C de-Avillez.
---
src/tail.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/tail.c b/src/tail.c
index 3c8f425..7d84bec 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -1231,7 +1231,7 @@ tail_forever_inotify (int wd, struct File_spec *f,
size_t n_files,
if (hash_insert (wd_table, (f[i])) == NULL)
xalloc_die ();
- if (follow_mode == Follow_name || f[i].wd)
+ if (follow_mode == Follow_name || 0 = f[i].wd)
Ten lines above that, we ensure that 0 = f[i].wd is true,
so this stmt:
if (follow_mode == Follow_name || 0 = f[i].wd)
is equivalent to this:
if (follow_mode == Follow_name || true)
aka,
if (true)
so perhaps that change should be larger:
- if (follow_mode == Follow_name || f[i].wd)
-found_watchable = true;
+ found_watchable = true;
Also, the initialization (farther above) of f[i].wd to a valid
file descriptor value (0) seems like a mistake:
- f[i].wd = 0;
+ f[i].wd = -1;
What do you think?
Agreed. I'll push the attached soon.
cheers,
Pádraig.
From 0126b5c9276f9206c8b2c35cd7890267c962ae31 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Wed, 12 Aug 2009 19:01:56 +0100
Subject: [PATCH] tail: fix tail -f failure when inotify used
* src/tail.c (tail_forever_inotify): Remove the redundant and
incorrect error check of the return from inotify_add_watch().
Also initialize the wd member of each File_spec to an invalid value.
Reported by C de-Avillez.
---
src/tail.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/tail.c b/src/tail.c
index 3c8f425..6f83706 100644
--- a/src/tail.c
+++ b/src/tail.c
@@ -1193,7 +1193,7 @@ tail_forever_inotify (int wd, struct File_spec *f, size_t n_files,
if (evlen fnlen)
evlen = fnlen;
- f[i].wd = 0;
+ f[i].wd = -1;
if (follow_mode == Follow_name)
{
@@ -1231,8 +1231,7 @@ tail_forever_inotify (int wd, struct File_spec *f, size_t n_files,
if (hash_insert (wd_table, (f[i])) == NULL)
xalloc_die ();
- if (follow_mode == Follow_name || f[i].wd)
-found_watchable = true;
+ found_watchable = true;
}
}
--
1.6.2.5
Re: no feedback on snapshot? coreutils-7.5 coming soon
Pádraig Brady wrote: Jim Meyering wrote: Pádraig Brady wrote: Subject: [PATCH] tail: fix tail -f failure when inotify used * src/tail.c (tail_inotify_forever): Use the correct bounds in the error check of the return from inotify_add_watch(). Reported by C de-Avillez. --- src/tail.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/tail.c b/src/tail.c index 3c8f425..7d84bec 100644 --- a/src/tail.c +++ b/src/tail.c @@ -1231,7 +1231,7 @@ tail_forever_inotify (int wd, struct File_spec *f, size_t n_files, if (hash_insert (wd_table, (f[i])) == NULL) xalloc_die (); - if (follow_mode == Follow_name || f[i].wd) + if (follow_mode == Follow_name || 0 = f[i].wd) Ten lines above that, we ensure that 0 = f[i].wd is true, so this stmt: if (follow_mode == Follow_name || 0 = f[i].wd) is equivalent to this: if (follow_mode == Follow_name || true) aka, if (true) so perhaps that change should be larger: - if (follow_mode == Follow_name || f[i].wd) -found_watchable = true; + found_watchable = true; Also, the initialization (farther above) of f[i].wd to a valid file descriptor value (0) seems like a mistake: - f[i].wd = 0; + f[i].wd = -1; What do you think? Agreed. I'll push the attached soon. Perfect. Thanks.
[PATCH] tests: raise ulimit virt-mem limit to avoid new failure
FYI, this test just barely failed on rawhide, so I've bumped the max virt mem limit up to 20,000 KB: From 11ccbdab27fc7b4f3c78e8a806745330534670f7 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Mon, 10 Aug 2009 09:28:45 +0200 Subject: [PATCH] tests: raise ulimit virt-mem limit to avoid new failure * tests/cp/link-heap: Raise limit from 16MB to ~20MB, to avoid spurious failure on rawhide. --- tests/cp/link-heap |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/cp/link-heap b/tests/cp/link-heap index 2433217..d9379b5 100755 --- a/tests/cp/link-heap +++ b/tests/cp/link-heap @@ -36,6 +36,6 @@ mkdir e || framework_failure mv $a $b e || framework_failure fail=0 -(ulimit -v 16000; cp -al e f) || fail=1 +(ulimit -v 2; cp -al e f) || fail=1 Exit $fail -- 1.6.4.357.gfd68c
Re: no feedback on snapshot? coreutils-7.5 coming soon
Pádraig Brady wrote: Pádraig Brady wrote: Jim Meyering wrote: AFAIK, I am the only one who has built the latest snapshot: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/17604 Though it's been only two days. Unless I hear of new bug reports or portability problems soon, expect coreutils-7.5 to be released in the next few days. checks pass on Fedora 11 and Ubuntu 7.10 2 failures on Fedora Core 5 due to copy::utimensat_if_possible() failing with: $ (cd tests make check TESTS=cp/abuse VERBOSE=yes) cp: preserving times for `c/1': No such file or directory $ (cd tests make check TESTS=mv/part-symlink VERBOSE=yes) mv: preserving times for `loc_reg': Too many levels of symbolic links These highlighted a couple of issue I think on systems without utimensat(). 1. The symlink _target_ gets its time updated 2. If 1 fails then the process returns a failure I've fixed both in the attached patch hopefully by only doing the explicit utimensat() on symlinks, and only giving a warning if errno==ENOTSUP. Thanks for working on that. Previously, copying with cp -a, symlink times would not be preserved (silently, since cp made no attempt). It sounds like with this change, on systems without utimensat, cp would print a warning for each and every symlink. Note it might be cleaner to add a O_NOFOLLOW flag to utimens() in gnulib, but that would be more invasive. I think changing only copy.c is ok, for now.
Re: Enhacement request - 'date' util
Alejandro Redondo wrote: Hi again, sorry about those HTML characters... I sent the first email from a webmail client. And sorry about my bad English too, it's not my natal language. I didn't notice anything wrong with your English, actually :-). (Why is it, I wonder, that non-native speakers always assume their English is bad? ;-) Or do us native speakers simply not notice because /our/ English is equally bad? And I am serious about that, English is a notoriously abused language and there are /very/ few people that use it properly. I'm not one of them.) Well, the first clock set, when ntpd starts, is made in just one step. Ideally that should be at system startup, when nothing that would get confused is running yet ;-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- ELANG: input is in wrong language (please use English on English lists)
Re: no feedback on snapshot? coreutils-7.5 coming soon
Jim Meyering wrote:
Pádraig Brady wrote:
These highlighted a couple of issues I think on systems without utimensat().
1. The symlink _target_ gets its time updated
2. If 1 fails then the process returns a failure
I've fixed both in the attached patch hopefully
by only doing the explicit utimensat() on symlinks,
and only giving a warning if errno==ENOTSUP.
Thanks for working on that.
Previously, copying with cp -a, symlink times would not be preserved
(silently, since cp made no attempt). It sounds like with this change,
on systems without utimensat, cp would print a warning for each and
every symlink.
I was wondering about printing the warning,
and was wary about now silently not preserving symlink times.
I.E. being silently inconsistent. I guess it's better
to be quiet in this case? That also means I can
reinstate the mv/part-symlink test on systems without utimensat().
Updated patch attached.
cheers,
Pádraig.
From cfd4e430bd433ce3b38561300accad1fa56ee89f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com
Date: Thu, 13 Aug 2009 10:39:10 +0100
Subject: [PATCH] cp,mv: fix issues with preserving timestamps of copied symlinks
* src/copy.c (copy_internal): On systems without utimensat() don't
use to utimens as that will set the timestamp of the symlink target.
* tests/cp/abuse: To work around possible attribute preservation
failures breaking the test, use cp -dR rather than cp -a.
---
src/copy.c | 19 +++
tests/cp/abuse |2 +-
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/src/copy.c b/src/copy.c
index bed90c4..73c1949 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -118,18 +118,18 @@ static bool owner_failure_ok (struct cp_options const *x);
static char const *top_level_src_name;
static char const *top_level_dst_name;
-/* Wrap utimensat-with-AT_FDCWD and utimens, to keep these
- cpp directives out of the main code. */
+/* Try to update the timestamp of a symlink.
+ We don't revert to utimens as that will follow the link. */
static inline int
-utimensat_if_possible (char const *file, struct timespec const *timespec)
+utimens_symlink (char const *file, struct timespec const *timespec)
{
- return
#if HAVE_UTIMENSAT
-utimensat (AT_FDCWD, file, timespec, AT_SYMLINK_NOFOLLOW)
+ return utimensat (AT_FDCWD, file, timespec, AT_SYMLINK_NOFOLLOW);
#else
-utimens (file, timespec)
+ /* Don't set errno=ENOTSUP here as we don't want
+ to output an error message for this case. */
+ return 0;
#endif
-;
}
/* Perform the O(1) btrfs clone operation, if possible.
@@ -2117,7 +2117,10 @@ copy_internal (char const *src_name, char const *dst_name,
timespec[0] = get_stat_atime (src_sb);
timespec[1] = get_stat_mtime (src_sb);
- if (utimensat_if_possible (dst_name, timespec) != 0)
+ if ((dest_is_symlink
+ ? utimens_symlink (dst_name, timespec)
+ : utimens (dst_name, timespec))
+ != 0)
{
error (0, errno, _(preserving times for %s), quote (dst_name));
if (x-require_preserve)
diff --git a/tests/cp/abuse b/tests/cp/abuse
index 285c531..e9086b8 100755
--- a/tests/cp/abuse
+++ b/tests/cp/abuse
@@ -37,7 +37,7 @@ for i in dangling-dest existing-dest; do
test $i = existing-dest echo i t
test $i = dangling-dest rm -f t
- cp -a a/1 b/1 c 2 out fail=1
+ cp -dR a/1 b/1 c 2 out fail=1
compare out exp || fail=1
--
1.6.2.5
[PATCH] doc: clarify the cp --reflink NEWS
From 3214858c9b53dcd8d2ef47473427fcd29dc56a7d Mon Sep 17 00:00:00 2001 From: =?utf-8?q?P=C3=A1draig=20Brady?= p...@draigbrady.com Date: Thu, 13 Aug 2009 17:25:09 +0100 Subject: [PATCH] doc: clarify the cp --reflink NEWS * NEWS: Remove the description associated with the removed experimental code which unconditionally tried to reflink() on copy. Also clarify where --reflink works exactly. --- NEWS |7 ++- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index a88546d..85cc82b 100644 --- a/NEWS +++ b/NEWS @@ -45,14 +45,11 @@ GNU coreutils NEWS-*- outline -*- chroot now accepts the options --userspec and --groups. cp accepts a new option, --reflink: create a lightweight copy - using copy-on-write (COW). This is currently supported only on - btrfs file systems. + using copy-on-write (COW). This is currently only supported within + a btrfs file system. cp now preserves time stamps on symbolic links, when possible - cp, install, mv: take advantage of btrfs' O(1) copy-on-write feature - when both the source and destination are on the same btrfs partition. - sort accepts a new option, --human-numeric-sort (-h): sort numbers while honoring human readable suffixes like KiB and MB etc.
Re: copyright years: mass-update every January 1
While at it, why not standardize everything to 4 digits Sounds like a good idea to me FWIW. The 2-digit years came about because rms optimized it with lawyers umpteen years ago. When I questioned him about it more recently (maybe only .3umpteen years :), he went back to the lawyers and this time the advice was to always use four-digit years. As usual with these matters, there is no pressing need to go back and change all the existing notices, but the more that get converted to the currently-standard form, the better. k
Docs for --preserve option
Hello everybody, Failing to understand --preserve option *after reading the man page*, I hope to help improving the docs so future users won't hit the same builder. The specific section at cp --help (from which cp man is generated) is: --preserve[=ATTR_LIST] preserve the specified attributes (default: mode,ownership,timestamps), if possible additional attributes: context, links, xattr, all Upon reading this I wrongly assumed that _failing to provide a preserve parameter_, it would preserve by default the mode, ownership and timestamps. I was annoyed on it seeing I needed to manually add --preserve=mode,ownership,timestamps and it wasn't working 'as documented' until I found the explanation in the Texinfo manual: Using `--preserve' with no ATTRIBUTE_LIST is equivalent to `--preserve=mode,ownership,timestamps'. In the absence of this option, each destination file is created with the mode bits of the corresponding source file, minus the bits set in the umask and minus the set-user-ID and set-group-ID bits. *Note File permissions::. I am attaching a rewording proposal that avoids talking about the default. If the mailing list strips plain text attachments I can send it to you directly. PS: You may want to fix http://www.gnu.org/software/coreutils/faq/coreutils-faq.html there're samp html tags visible inside anchor tags. diff --git a/src/cp.c b/src/cp.c index c99aff3..5577c89 100644 --- a/src/cp.c +++ b/src/cp.c @@ -181,10 +181,10 @@ Mandatory arguments to long options are mandatory for short options too.\n\ ), stdout); fputs (_(\ -p same as --preserve=mode,ownership,timestamps\n\ - --preserve[=ATTR_LIST] preserve the specified attributes (default:\n\ - mode,ownership,timestamps), if possible\n\ - additional attributes: context, links, xattr,\n\ - all\n\ + --preserve[=ATTR_LIST] preserve the specified attributes (without\n\ + ATTR_LIST: mode,ownership,timestamps), if\n\ + possible. Additional attributes: context,\n\ + links, xattr, all\n\ ), stdout); fputs (_(\ --no-preserve=ATTR_LIST don't preserve the specified attributes\n\
Re: copyright years: mass-update every January 1
On Thu, 13 Aug 2009, Eric Blake wrote: According to Akim Demaille on 8/13/2009 1:59 AM: - Copyright (C) 89, 90, 91, 1995-2006, 2008-2009 Free Software - Foundation, Inc. + Copyright (C) 89, 90, 91, 1995-2006, 2008-2009 Free Software Foundation, Inc. While at it, why not standardize everything to 4 digits (I don't think we need to address the Y10k issues yet :), and to introduce intervals where applicable? Is there some legal thingy that forbids it? It might help making some lines smaller. Yes - see this post: http://lists.gnu.org/archive/html/bug-gnulib/2009-08/msg00184.html I'm not personally opposed to compressed years, but if you want the tool to output compressed years instead of longhand, it should be an option (and more importantly, we should also fix the tool to allow longhand years for maintainers that want longhand). Below are some patches to implement that. From 75dd6c0c64ee03ebb4eb7b0b14cf8905b9ad65ad Mon Sep 17 00:00:00 2001 From: Joel E. Denny jde...@clemson.edu Date: Thu, 13 Aug 2009 22:40:34 -0400 Subject: [PATCH] update-copyright: convert 2-digit to 4-digit years * build-aux/update-copyright: Implement and document. * tests/test-update-copyright.sh: Update. --- ChangeLog |6 ++ build-aux/update-copyright | 13 + tests/test-update-copyright.sh | 36 ++-- 3 files changed, 33 insertions(+), 22 deletions(-) diff --git a/ChangeLog b/ChangeLog index d6c3670..8ceadbf 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2009-08-14 Joel E. Denny jde...@clemson.edu + + update-copyright: convert 2-digit to 4-digit years + * build-aux/update-copyright: Implement and document. + * tests/test-update-copyright.sh: Update. + 2009-08-13 Eric Blake e...@byu.net test-dup2: fix bad assumption diff --git a/build-aux/update-copyright b/build-aux/update-copyright index 68440f8..fb1c7d2 100755 --- a/build-aux/update-copyright +++ b/build-aux/update-copyright @@ -1,7 +1,7 @@ #!/usr/bin/perl -0777 -pi # Update an FSF copyright year list to include the current year. -my $VERSION = '2009-08-06.01:08'; # UTC +my $VERSION = '2009-08-14.02:23'; # UTC # Copyright (C) 2009 Free Software Foundation, Inc. # @@ -26,9 +26,11 @@ my $VERSION = '2009-08-06.01:08'; # UTC # maintainer-makefile module. # # Iff an FSF copyright statement is discovered in a file and the final -# year is not the current year, the statement is updated for the new -# year and reformatted to fit within 72 columns. A warning is printed -# for every file for which no FSF copyright statement is discovered. +# year is not the current year, then the statement is updated for the +# new year, 2-digit years are converted to 4-digit years by prepending +# 19, and the statement is reformatted to fit within 72 columns. A +# warning is printed for every file for which no FSF copyright statement +# is discovered. # # Each file's FSF copyright statement must be formated correctly in # order to be recognized. For example, each of these is fine: @@ -179,6 +181,9 @@ if (defined $stmt_re) # Put spaces after commas. $stmt =~ s/, ?/, /g; +# Convert 2-digit to 4-digit years. +$stmt =~ s/(\b\d\d\b)/19$1/g; + # Format within margin. my $stmt_wrapped; my $text_margin = $margin - length($prefix); diff --git a/tests/test-update-copyright.sh b/tests/test-update-copyright.sh index 9997df4..d0e3083 100755 --- a/tests/test-update-copyright.sh +++ b/tests/test-update-copyright.sh @@ -123,7 +123,7 @@ compare - $TMP.2 EOF || exit 1 EOF compare - $TMP.3 EOF || exit 1 /* - * Copyright copy; 90, 2005, 2007-2010 Free Software Foundation, Inc. + * Copyright copy; 1990, 2005, 2007-2010 Free Software Foundation, Inc. */ EOF compare - $TMP.4 EOF || exit 1 @@ -284,9 +284,9 @@ UPDATE_COPYRIGHT_YEAR=2010 \ compare /dev/null $TMP-stdout || exit 1 compare /dev/null $TMP-stderr || exit 1 compare - $TMP EOF || exit 1 - Copyright (C) 87, 88, 1991, 1992, 1993, 1994, 1995, 1996, 1997, - 98, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, - 2009-2010 Free Software Foundation, Inc. + Copyright (C) 1987, 1988, 1991, 1992, 1993, 1994, 1995, 1996, + 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, + 2007, 2008, 2009-2010 Free Software Foundation, Inc. EOF rm $TMP* @@ -305,9 +305,9 @@ UPDATE_COPYRIGHT_YEAR=2010 \ compare /dev/null $TMP-stdout || exit 1 compare /dev/null $TMP-stderr || exit 1 compare - $TMP EOF || exit 1 - # Copyright (C) 87, 88, 1991, 1992, 1993, 1994, 1995, - # 1996, 1997, 98, 1999, 2000, 2001, 2002, 2003, 2004, - # 2005, 2006, 2007, 2008, 2009-2010 Free Software + # Copyright (C) 1987, 1988, 1991, 1992, 1993, 1994, + # 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, + # 2004, 2005, 2006,
