bug#10636: chown verbose option (-v) reports incorrect retained owner:group
Tero Nieminen wrote: I just noticed that when I use chown like this: chown -hRv --from=500:500 1000:1000 nnn (as root) it prints incorrect information on retained owner:group, like this: ownership of `nnn/lost+found' retained as 1000:1000 Ie. instead of printing the actual retained owner and group (in this case root:root) it seems to incorrectly print the owner:group I was trying to change to. Is this maybe a bug in Gnu-coreutils/chown or just in the particular version (8.12) shipped with Fedora 16 (coreutils-8.12-2.fc16.x86_64)? I could Only found a single non-bug for chown in debbugs.gnu.org (maybe I just don't know how to search ;). Thank you for noticing and reporting that bug. You guessed it. It is specific to Fedora's version of chown. I.e., when I try to reproduce it with the chown from stock coreutils-8.15, it works as expected. Actually, this can be demonstrated by non-root. The F16-supplied chown (coreutils-8.12-2.fc16.x86_64) fails: $ /bin/chown -v --from=1:1 $UID:$UID / ownership of `/' retained as 1000:1000 When I run the one from coreutils-8.15, it works as expected: $ chown -v --from=1:1 $UID:$UID / : ownership of '/' retained as root:root If this is fixed or nonexistent in GNU-coreutils, I'll file the bug to Fedora. Thanks!
bug#10636: chown verbose option (-v) reports incorrect retained owner:group
tags 10636 notabug thanks ... Thank you for noticing and reporting that bug. You guessed it. It is specific to Fedora's version of chown. I.e., when I try to reproduce it with the chown from stock coreutils-8.15, it works as expected. Oh, and since it's not an upstream bug, I'm marking it as such and closing its ticket.
bug#10636: chown verbose option (-v) reports incorrect retained owner:group
Jim Meyering wrote: tags 10636 notabug thanks ... Thank you for noticing and reporting that bug. You guessed it. It is specific to Fedora's version of chown. I.e., when I try to reproduce it with the chown from stock coreutils-8.15, it works as expected. Oh, and since it's not an upstream bug, I'm marking it as such and closing its ticket. Finally, this was fixed by upstream commit v8.12-59-g6b282e7: http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=6b282e7510ca8d
bug#10423: problem with make check coreutils-8.14 after build on AIX (v5.3, xlc v7, ksh as default shell)
tags 10423 + moreinfo thanks Michael Felt wrote: (Happy New Year - aside) configured and compiled coreutils without incident, however make check fails at the same spot for both root and non-root. The test fails saying /bin/sh: not found Thanks again for the report. Now that coreutils-8.15 is released, would you please see if you can still reproduce this failure with it? http://ftp.gnu.org/gnu/coreutils/coreutils-8.15.tar.xz
bug#6554: [PATCH] split: Additional suffix for split (bug#6554)
On 01/28/2012 00:00 AM, Pádraig Brady wrote: On 01/28/2012 11:57 PM, Jérémy Compostella wrote: [...] I should note that --suffix is incompatible with a variable length generated suffix. I.E. one that would allow for arbitrary sized input: http://lists.gnu.org/archive/html/bug-coreutils/2009-09/msg00220.html Though I guess that functionality could still be provided if required, by specifying --suffix-length=auto and having that mutually exclusive with --suffix. First, after having carefully read the thread you are talking about I did not find any implementation of this in the current coreutils repository. Anyway, this feature is interesting and I would be glad to implement it if needs too but in another commit. Yes, this feature was removed from coreutils. Anyway something to worry about later. Second, I don't get your point. Why it should not be possible to append a fixed length suffix to output files with a variable length dynamic suffix ? I do not figure out why it's incompatible. What do I misunderstood ? To allow processing the split files in order. If the supplied suffix is overlapping part of a generated suffix, then there is no way to subsequently sort the parts. For example, the following hypothetical split command call looks perfectly compatible: $ split -b10 --suffix-length=auto --suffix=.txt file.txt file. $ ls file.aa.txt [...] file.yz.txt file.zaaa.txt This example is usually OK as '.' will sort before letters. If one has a --suffix without a '.' though, then we've problems. This is just an edge case worth noting. Thanks, I get it now. IMHO these options should not be mutual exclusives but the documentation should mention the variable length dynamic suffix algorithm and warn about this behavior. In that case the user will be able to have the precise behavior he wants without a systematic constraint. As for the patch, it seems to work :) t$ seq 10 file.txt t$ ../split -n10 --suffix=.txt file.txt file. t$ l -rw-rw-r--. 1 padraig 21 Jan 28 14:06 file.txt -rw-rw-r--. 1 padraig 3 Jan 28 14:06 file.aj.txt -rw-rw-r--. 1 padraig 2 Jan 28 14:06 file.ai.txt -rw-rw-r--. 1 padraig 2 Jan 28 14:06 file.ah.txt -rw-rw-r--. 1 padraig 2 Jan 28 14:06 file.ag.txt -rw-rw-r--. 1 padraig 2 Jan 28 14:06 file.af.txt -rw-rw-r--. 1 padraig 2 Jan 28 14:06 file.ae.txt -rw-rw-r--. 1 padraig 2 Jan 28 14:06 file.ad.txt -rw-rw-r--. 1 padraig 2 Jan 28 14:06 file.ac.txt -rw-rw-r--. 1 padraig 2 Jan 28 14:06 file.ab.txt -rw-rw-r--. 1 padraig 2 Jan 28 14:06 file.aa.txt We'd need some corresponding documentation in doc/coreutils.texi, and an entry in NEWS. I added the corresponding documentation in both of files. I've done my best but feel free to comment my additions. Also even thought the patch is small, you'd need to start the copyright assignment process for a new parameter to `split`. I filled out and sent my coreutils assignment form. Excellent thanks. Jeremy
bug#10305: coreutils-8.14, rm -r fails with EBADF
severity 10305 wishlist tags 10305 + notabug thanks Eric Blake wrote: On 12/21/2011 11:42 AM, Paul Eggert wrote: On 12/21/11 08:27, Eric Blake wrote: maybe we should wrap opendir() so that the gnulib rpl_opendir() always opens a directory at the same time That sounds a bit drastic, but it may be necessary. How about this idea instead? Use the following patch, so that fts_build does not assume that dirfd works. POSIX does not require dirfd to work, Actually, the next version of POSIX _will_ require dirfd to work, so we may have to go with wrapping rpl_opendir anyways: http://austingroupbugs.net/view.php?id=391 But you are correct that older systems do not meet the future POSIX wording, so if your hack works, it's certainly simpler for the short term. It is clear that this is not really a bug in coreutils, but more an opportunity to (through gnulib) make fts, and thus rm portable to this aspect of NonStop. Marked as notabug and wishlist.
bug#6960: mv refuses to move a symlink over a hard link to the same file
Paul Eggert wrote: On 01/04/12 14:30, Jim Meyering wrote: You could form the symlink-free full name of the referent, abs_src and then test same_name (abs_src, dst_name). That doesn't sound right, since the symlink may resolve differently after it's moved. For example: Hi Paul, Interesting point. Thanks. $ ls -ldt lt ny d d/lt.new drwxr-xr-x. 2 eggert eggert 4096 Jan 4 14:44 d lrwxrwxrwx. 1 eggert eggert2 Jan 4 14:26 d/lt.new - ny -rw-r--r--. 2 eggert eggert2 Jan 4 14:26 lt -rw-r--r--. 2 eggert eggert2 Jan 4 14:26 ny $ mv d/lt.new ny However, your example is not relevant, because the source is a mere dangling symlink. Thus, it doesn't meet the requirements for that similarity check to be invoked. Perhaps you meant something like this: $ rm -f [dfgs]; mkdir d; touch f; ln f g; ln -s ../f d/k; env mv d/k g mv: 'd/k' and 'g' are the same file $ ls -ogi f g d/k 75574240 lrwxrwxrwx. 1 4 Jan 29 19:43 d/k - ../f 75574239 -rw---. 2 0 Jan 29 19:43 f 75574239 -rw---. 2 0 Jan 29 19:43 g And in that case, I find it hard to imagine a legitimate use in which one would want to move such a relative symlink onto its referent at a different level of the hierarchy. So maybe we don't need to add a conjunct for that case after all. ... I'm becoming more inclined to think that Anders's argument: mv is already perfectly happy to atomically overwrite a regular file with a symlink (even if that causes data loss) is a valid one. If your/Anders' point is that moving an arbitrary symlink onto an unrelated regular file can unlink the final copy of the target, well, yes, that's true, but there's nothing subtle or unusual about that case, while there is in the cases that mv does reject. mv calls rename, so of course it must induce data loss. The point of this exception is to reject the very few cases that indicate user error with very high probability. Here's a more complete patch: From 799b7f7c6f27a5356e76861066dfa554d3951f0d Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Thu, 5 Jan 2012 11:45:50 +0100 Subject: [PATCH] mv: allow moving symlink onto same-inode dest with = 2 hard links Normally, mv detects a few subtle cases in which proceeding with a same-file rename would, with very high probability, cause data loss. Here, we have found a corner case in which one of these same-inode tests makes mv refuse to perform a useful operation. Permit that corner case. * src/copy.c (same_file_ok): Detect/exempt this case. * tests/mv/symlink-onto-hardlink: New test. * tests/Makefile.am (TESTS): Add it. * NEWS (Bug fixes): Mention it. Initially reported by: Matt McCutchen in http://bugs.gnu.org/6960. Raised again by Anders Kaseorg due to http://bugs.debian.org/654596. --- NEWS |9 THANKS.in |2 + src/copy.c | 37 tests/Makefile.am |1 + tests/mv/symlink-onto-hardlink | 41 5 files changed, 90 insertions(+), 0 deletions(-) create mode 100755 tests/mv/symlink-onto-hardlink diff --git a/NEWS b/NEWS index 2b0926f..9eebbf6 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,15 @@ GNU coreutils NEWS-*- outline -*- * Noteworthy changes in release ?.? (-??-??) [?] +** Bug fixes + + mv now lets you move a symlink onto a same-inode destination file that + has two or more hard links. Before, it would reject that, saying that + they are the same, implicitly warning you that the move would result in + data loss. In this unusual case, when not moving the symlink onto its + referent, there is no risk of data loss, since the symlink will + typically still point to one of the hard links. + * Noteworthy changes in release 8.15 (2012-01-06) [stable] diff --git a/THANKS.in b/THANKS.in index 13c8817..904bb3e 100644 --- a/THANKS.in +++ b/THANKS.in @@ -39,6 +39,7 @@ Alexey Vyskubov ale...@pippuri.mawhrin.net Alfred M. Szmidta...@kemisten.nu Ambrose Feinstein ambr...@google.com Amr Ali amr.ali...@gmail.com +Anders Kaseorg ande...@mit.edu Andi Kleen frei...@alancoxonachip.com Andre Novaes Cunha andre.cu...@br.global-one.net Andreas Frische andreasfris...@gmail.com @@ -384,6 +385,7 @@ Mate Wierdl m...@moni.msci.memphis.edu Matej Vela mv...@public.srce.hr Matias A. Fonzo s...@dragora.org Matt Kraai kr...@ftbfs.org +Matt McCutchen m...@mattmccutchen.net Matt Perry m...@primefactor.com Matt Pham mattvp...@gmail.com Matt Schalitmscha...@pacbell.net diff --git a/src/copy.c
bug#6960: mv refuses to move a symlink over a hard link to the same file
On 01/29/2012 09:33 PM, Jim Meyering wrote:
diff --git a/src/copy.c b/src/copy.c
index 51f51be..af79ed3 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -34,6 +34,7 @@
#include acl.h
#include backupfile.h
#include buffer-lcm.h
+#include canonicalize.h
#include copy.h
#include cp-hash.h
#include extent-scan.h
@@ -1349,6 +1350,38 @@ same_file_ok (char const *src_name, struct stat const
*src_sb,
}
}
+ /* At this point, it is normally an error (data loss) to move a symlink
+ onto its referent, but in at least one narrow case, it is not:
+ In move mode, when
+ src is a symlink,
+ dest is not a symlink,
+ dest has a link count of 2 or more and
+ dest and the referent of src are not the same entry,
+ then it's ok, since while we'll lose one of those hard links,
+ src will still point to a remaining link.
+
+ Given this,
+ $ touch f ln f l ln -s f s
+ $ ls -og f l s
+ -rw---. 2 0 Jan 4 22:46 f
+ -rw---. 2 0 Jan 4 22:46 l
+ lrwxrwxrwx. 1 1 Jan 4 22:46 s - f
+ this must fail: mv s f
+ this must succeed: mv s l */
+ if (x-move_mode
+ S_ISLNK (src_sb-st_mode)
+ ! S_ISLNK (dst_sb-st_mode)
+ 1 dst_sb_link-st_nlink)
+{
+ char *abs_src = canonicalize_file_name (src_name);
+ if (abs_src)
+{
+ bool result = ! same_name (abs_src, dst_name);
+ free (abs_src);
+ return result;
+}
+}
Well the logic follows the description at least.
I was going to say the nlink test was redundant,
but it's a bit clearer with that left, and also
it's a performance improvement in the nlink=1 case.
cheers,
Pádraig.
bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.
Pádraig, Sci-Fi, others,
I made an implementation of the requested feature. With the attached
patch applied the split command accepts a new optional from argument
for the --numeric-suffixes (aka -d) option. If this argument is
specified, the numeric suffix counts from this value, otherwise, like
before, it counts from 0.
I've tried to not impact the performance, to not break anything and to
respect the coding rules but feel free to comment this patch. I will
take into account whatever you may want.
Cheers,
Jérémy
---
From 82cbcf36e1fc9901964b6a348b495739357f28ee Mon Sep 17 00:00:00 2001
From: Jeremy Compostella jeremy.composte...@gmail.com
Date: Sun, 29 Jan 2012 15:20:31 +0100
Subject: [PATCH] split: --numeric-suffixes new optional from argument (bug#9085)
The split command now accepts a new optional from argument for the
--numeric-suffixes (aka -d) option. When this argument is specified,
the numeric suffix counts from this value, otherwise, like before, it
counts from 0.
Signed-off-by: Jeremy Compostella jeremy.composte...@gmail.com
---
NEWS |6 +
doc/coreutils.texi |7 +++--
src/split.c| 63 +++-
3 files changed, 67 insertions(+), 9 deletions(-)
diff --git a/NEWS b/NEWS
index 2b0926f..2f46707 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,12 @@ GNU coreutils NEWS-*- outline -*-
* Noteworthy changes in release ?.? (-??-??) [?]
+** New features
+
+ split now accept an optional from value for the
+ --numeric-suffixes (aka -d) option. When this argument is
+ specified, the numeric suffix counts from this value, otherwise,
+ like before, it counts from 0.
* Noteworthy changes in release 8.15 (2012-01-06) [stable]
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 0d3b739..53ab356 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3083,11 +3083,12 @@ and so can be a pipe for example.
@opindex --suffix-length
Use suffixes of length @var{length}. The default @var{length} is 2.
-@item -d
-@itemx --numeric-suffixes
+@item -d[@var{from}]
+@itemx --numeric-suffixes[=@var{from}]
@opindex -d
@opindex --numeric-suffixes
-Use digits in suffixes rather than lower-case letters.
+Use digits in suffixes rather than lower-case letters. The numerical
+suffix counts from @var{from} if specified, 0 otherwise.
@item -e
@itemx --elide-empty-files
diff --git a/src/split.c b/src/split.c
index 5fbce0e..7454bc2 100644
--- a/src/split.c
+++ b/src/split.c
@@ -80,6 +80,9 @@ static size_t suffix_length;
/* Alphabet of characters to use in suffix. */
static char const *suffix_alphabet = abcdefghijklmnopqrstuvwxyz;
+/* Numerical suffix count from value. */
+static size_t suffix_count_from;
+
/* Name of input file. May be -. */
static char *infile;
@@ -122,7 +125,7 @@ static struct option const longopts[] =
{elide-empty-files, no_argument, NULL, 'e'},
{unbuffered, no_argument, NULL, 'u'},
{suffix-length, required_argument, NULL, 'a'},
- {numeric-suffixes, no_argument, NULL, 'd'},
+ {numeric-suffixes, optional_argument, NULL, 'd'},
{filter, required_argument, NULL, FILTER_OPTION},
{verbose, no_argument, NULL, VERBOSE_OPTION},
{-io-blksize, required_argument, NULL,
@@ -195,7 +198,8 @@ Mandatory arguments to long options are mandatory for short options too.\n\
-a, --suffix-length=N use suffixes of length N (default %d)\n\
-b, --bytes=SIZEput SIZE bytes per output file\n\
-C, --line-bytes=SIZE put at most SIZE bytes of lines per output file\n\
- -d, --numeric-suffixes use numeric suffixes instead of alphabetic\n\
+ -d[FROM], --numeric-suffixes[FROM] use numeric suffixes instead of alphabetic.\n\
+ When specified, start counting from FROM, 0 otherwise\n\
-e, --elide-empty-files do not generate empty output files with '-n'\n\
--filter=COMMANDwrite to shell COMMAND; file name is $FILE\n\
-l, --lines=NUMBER put NUMBER lines per output file\n\
@@ -231,6 +235,7 @@ next_file_name (void)
{
/* Index in suffix_alphabet of each character in the suffix. */
static size_t *sufindex;
+ size_t i = suffix_length;
if (! outfile)
{
@@ -243,9 +248,23 @@ next_file_name (void)
outfile = xmalloc (outfile_length + 1);
outfile_mid = outfile + outbase_length;
memcpy (outfile, outbase, outbase_length);
- memset (outfile_mid, suffix_alphabet[0], suffix_length);
- outfile[outfile_length] = 0;
sufindex = xcalloc (suffix_length, sizeof *sufindex);
+ /* Initialize the suffix index accordingly to the count from
+ value. */
+ {
+size_t left = suffix_count_from;
+while (i-- != 0)
+ {
+if (left)
+ {
+sufindex[i] = left % 10;
+left /= 10;
+ }
+outfile_mid[i] = suffix_alphabet[sufindex[i]];
+ }
+ }
+
+
bug#10639: BUG REPORT coreutils-8.15 Solaris 10 64bit
Thanks for the bug report. What kind of file system was the test run on, and what mount options were used for it? E.g., what's the output of the mount command? Also, what's the output of uname -a, and which compiler did you use to build coreutils?
