bug#6960: mv refuses to move a symlink over a hard link to the same file
Pádraig Brady wrote:
On 01/29/2012 09:33 PM, Jim Meyering wrote:
..
+ /* 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.
Thanks for the review.
I'll wait a day or so more, in case Paul or anyone else has feedback.
BTW, I removed the
x-dereference == DEREF_NEVER
test that I'd used in the first version, since
in move mode, that condition is always true.
bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.
On 01/29/2012 10:34 PM, Jérémy Compostella wrote:
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.
Thanks again for looking at this.
It's a useful feature for the presented use case,
or for supporting multiple independent split invocations.
Note we rarely change an option to have optional args.
For optional args, no space is allowed between option name and value.
I.E. --numeric-suffixes=10 or -d10 is required, which is a little restrictive.
More problematically though, existing scripts using the short options -de or
-du in
combination will break. The -eu options are relatively new though, so I'm
leaning
towards this being acceptable. Hmm, this unusual form would fail too, `split
-da3 ...`.
The failure mode is immediate and obvious, but this worries me a bit.
I wonder might we have a separate option, --suffix-start,
and theoretically that could accept alphabetic options too?
I'm not suggesting we do this, but it's worth discussing.
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)
+ -d[FROM], --numeric-suffixes[FROM] use numeric suffixes instead of
alphabetic.\n\
+ When specified, start counting from FROM, 0
otherwise\n\
s/-d[FROM], --numeric-suffixes[FROM]/-d, --numeric-suffixes[=FROM]
-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]];
+ }
+ }
+
+ outfile[outfile_length] = 0;
#if ! _POSIX_NO_TRUNC HAVE_PATHCONF defined _PC_NAME_MAX
/* POSIX requires that if the output file name is too long for
@@ -265,7 +284,6 @@ next_file_name (void)
{
/* Increment the suffix in place, if possible. */
- size_t i = suffix_length;
while (i-- != 0)
{
sufindex[i]++;
@@ -1016,7 +1034,7 @@ main (int argc, char **argv)
int this_optind = optind ? optind : 1;
char *slash;
- c = getopt_long (argc, argv, 0123456789C:a:b:del:n:u,
+ c = getopt_long (argc, argv, 0123456789C:a:b:d::el:n:u,
longopts, NULL);
if (c == -1)
break;
@@ -1142,6 +1160,19 @@ main (int argc, char **argv)
case 'd':
suffix_alphabet = 0123456789;
+ if (optarg)
+{
+ unsigned long tmp;
+ if (xstrtoul (optarg, NULL, 10, tmp, ) != LONGINT_OK
+ || SIZE_MAX / sizeof (size_t) tmp)
Note the SIZE_MAX/sizeof(size_t) restriction was on the -a option,
as that is later used in a malloc. For -d there would be
no such restriction, so I'd just use xstrtoumax() != LONGINT_OK
cheers,
Pádraig.
bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.
On 01/30/2012 10:29 AM, Pádraig Brady wrote: On 01/29/2012 10:34 PM, Jérémy Compostella wrote: 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. Thanks again for looking at this. It's a useful feature for the presented use case, or for supporting multiple independent split invocations. Note we rarely change an option to have optional args. For optional args, no space is allowed between option name and value. I.E. --numeric-suffixes=10 or -d10 is required, which is a little restrictive. More problematically though, existing scripts using the short options -de or -du in combination will break. The -eu options are relatively new though, so I'm leaning towards this being acceptable. Hmm, this unusual form would fail too, `split -da3 ...`. The failure mode is immediate and obvious, but this worries me a bit. I wonder might we have a separate option, --suffix-start, and theoretically that could accept alphabetic options too? I'm not suggesting we do this, but it's worth discussing. Think a bit more about it, it's probably worth to split the short and long options. Have -d not take a param as before, and have --numeric-suffixes take an optional param. cheers, Pádraig.
bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.
Pádraig Brady wrote: On 01/30/2012 10:29 AM, Pádraig Brady wrote: On 01/29/2012 10:34 PM, Jérémy Compostella wrote: 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. Thanks again for looking at this. It's a useful feature for the presented use case, or for supporting multiple independent split invocations. Note we rarely change an option to have optional args. For optional args, no space is allowed between option name and value. I.E. --numeric-suffixes=10 or -d10 is required, which is a little restrictive. More problematically though, existing scripts using the short options -de or -du in combination will break. The -eu options are relatively new though, so I'm leaning towards this being acceptable. Hmm, this unusual form would fail too, `split -da3 ...`. The failure mode is immediate and obvious, but this worries me a bit. I wonder might we have a separate option, --suffix-start, and theoretically that could accept alphabetic options too? I'm not suggesting we do this, but it's worth discussing. Think a bit more about it, it's probably worth to split the short and long options. Have -d not take a param as before, and have --numeric-suffixes take an optional param. I agree. We try hard to avoid short options with optional args for the reasons you've outlined above.
bug#6960: mv refuses to move a symlink over a hard link to the same file
Pádraig Brady wrote:
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.
That's a good point.
I've added it:
/* 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
1) src is a symlink,
2) dest is not a symlink,
3) dest has a link count of 2 or more and
4) 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.
Note that technically, condition #4 obviates condition #2, but we
retain the 1 st_nlink condition because that means fewer invocations
of the more expensive #4.
...
bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.
Thanks to both you for looking at this patch. I'm a bit busy right now. I will take your proposition into account as soon as possible. Exceptionaly, I do not have access to a computer during the day this week. I only have access to my mailbox via my phone. Cheers, Jeremy Le 30 janv. 2012 12:07, Jim Meyering j...@meyering.net a écrit : Pádraig Brady wrote: On 01/30/2012 10:29 AM, Pádraig Brady wrote: On 01/29/2012 10:34 PM, Jérémy Compostella wrote: 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. Thanks again for looking at this. It's a useful feature for the presented use case, or for supporting multiple independent split invocations. Note we rarely change an option to have optional args. For optional args, no space is allowed between option name and value. I.E. --numeric-suffixes=10 or -d10 is required, which is a little restrictive. More problematically though, existing scripts using the short options -de or -du in combination will break. The -eu options are relatively new though, so I'm leaning towards this being acceptable. Hmm, this unusual form would fail too, `split -da3 ...`. The failure mode is immediate and obvious, but this worries me a bit. I wonder might we have a separate option, --suffix-start, and theoretically that could accept alphabetic options too? I'm not suggesting we do this, but it's worth discussing. Think a bit more about it, it's probably worth to split the short and long options. Have -d not take a param as before, and have --numeric-suffixes take an optional param. I agree. We try hard to avoid short options with optional args for the reasons you've outlined above.
bug#10639: BUG REPORT coreutils-8.15 Solaris 10 64bit
Paul, SUN Solaris 10 The FS are a mix. Some vxfs and some ufs. $ mount / on /dev/vx/dsk/bootdg/rootvol read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=434 on Sat Jan 21 05:16:53 2012 /devices on /devices read/write/setuid/devices/dev=578 on Sat Jan 21 05:13:16 2012 /system/contract on ctfs read/write/setuid/devices/dev=57c0001 on Sat Jan 21 05:13:16 2012 /proc on proc read/write/setuid/devices/dev=580 on Sat Jan 21 05:13:16 2012 /etc/mnttab on mnttab read/write/setuid/devices/dev=5840001 on Sat Jan 21 05:13:16 2012 /etc/svc/volatile on swap read/write/setuid/devices/xattr/dev=5880001 on Sat Jan 21 05:13:16 2012 /system/object on objfs read/write/setuid/devices/dev=58c0001 on Sat Jan 21 05:13:16 2012 /etc/dfs/sharetab on sharefs read/write/setuid/devices/dev=591 on Sat Jan 21 05:13:17 2012 /platform/sun4u-us3/lib/libc_psr.so.1 on /platform/sun4u-us3/lib/libc_psr/libc_psr_hwcap2.so.1 read/write/setuid/devices/dev=434 on Sat Jan 21 05:16:50 2012 /platform/sun4u-us3/lib/sparcv9/libc_psr.so.1 on /platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap2.so.1 read/write/setuid/devices/dev=434 on Sat Jan 21 05:16:50 2012 /dev/fd on fd read/write/setuid/devices/dev=5a80001 on Sat Jan 21 05:16:53 2012 /var on /dev/vx/dsk/bootdg/var read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=4356764 on Sat Jan 21 05:16:53 2012 /tmp on swap read/write/setuid/devices/xattr/dev=5880002 on Sat Jan 21 05:16:53 2012 /var/run on swap read/write/setuid/devices/xattr/dev=5880003 on Sat Jan 21 05:16:53 2012 /dev/vx/dmp on swap read/write/setuid/devices/xattr/dev=5880004 on Sat Jan 21 05:16:55 2012 /dev/vx/rdmp on swap read/write/setuid/devices/xattr/dev=5880005 on Sat Jan 21 05:16:55 2012 /extra on /dev/vx/dsk/bootdg/extra read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=4356762 on Sat Jan 21 05:17:12 2012 /export/home on /dev/vx/dsk/bootdg/home read/write/setuid/devices/intr/largefiles/logging/xattr/onerror=panic/dev=4356763 on Sat Jan 21 05:17:12 2012 /appl/logs on /dev/vx/dsk/appldg/vol07 read/write/setuid/devices/delaylog/largefiles/ioerror=mwdisable/dev=43459de on Sat Jan 21 05:17:13 2012 /appl/repos on /dev/vx/dsk/appldg/vol02 read/write/setuid/devices/delaylog/largefiles/ioerror=mwdisable/dev=43459d9 on Sat Jan 21 05:17:13 2012 /appl/archives on /dev/vx/dsk/appldg/vol06 read/write/setuid/devices/delaylog/largefiles/ioerror=mwdisable/dev=43459dd on Sat Jan 21 05:17:13 2012 /appl/gfpip on /dev/vx/dsk/appldg/vol01 read/write/setuid/devices/delaylog/largefiles/ioerror=mwdisable/dev=43459d8 on Sat Jan 21 05:17:14 2012 /appl/var on /dev/vx/dsk/appldg/vol05 read/write/setuid/devices/delaylog/largefiles/ioerror=mwdisable/dev=43459dc on Sat Jan 21 05:17:15 2012 /appl/data on /dev/vx/dsk/appldg/vol04 read/write/setuid/devices/delaylog/largefiles/ioerror=mwdisable/dev=43459db on Sat Jan 21 05:17:15 2012 /appl/IBM on /dev/vx/dsk/appldg/lvol13 read/write/setuid/devices/delaylog/largefiles/ioerror=mwdisable/dev=43459e4 on Wed Jan 25 15:56:39 2012 /nas/usr/sbc on r07748fb1n1-nas:/vol/v00_fs01_admin/q00_fs01_admin/sun remote/read only/setuid/devices/soft/bg/noquota/proto=tcp/xattr/dev=5b005a6 on Mon Jan 30 05:19:08 2012 SunOS gfpmtipb 5.10 Generic_142900-06 sun4u sparc SUNW,Netra-T12 Solaris Bill From: Paul Eggert [egg...@cs.ucla.edu] Sent: Sunday, January 29, 2012 11:55 PM To: JONES, BILL Cc: 10...@debbugs.gnu.org Subject: Re: 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?
bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.
Pádraig, Jim, others, - Solution 1: Pádraig wrotes: I wonder might we have a separate option, --suffix-start, and theoretically that could accept alphabetic options too? I'm not suggesting we do this, but it's worth discussion. That's was my first idea but since your first mail subject was split --numeric-suffixes=N I assumed that you already thought about it as a bad solution. Wrong assumption I guess. - Solution 2: Pádraig wrotes: Thinking a bit more about it, it's probably worth to split the short and long options. Have -d not take a param as before, and have --numeric-suffixes take an optional param. To do this, leave 'optional_argument' in the long_opts array, and just remove the :: from the getopts call. Personally, I do prefer the Solution 1 since the result looks more consistent, more powerful andf does not change anything to the current options. However, it needs more work. It's a very particular week for me and I will probably miss time and energy to work on this solution before next week-end. Anyway, we can talk about the best solution to implement so let me know. - Note: Pádraig wrotes: Note the SIZE_MAX/sizeof(size_t) restriction was on the -a option, as that is later used in a malloc. For -d there would be no such restriction, so I'd just use xstrtoumax() != LONGINT_OK OK, thanks for the note and explanation, I will take this into account. Cheers, Jérémy
bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.
On 01/30/2012 05:33 PM, Jérémy Compostella wrote: Pádraig, Jim, others, - Solution 1: Pádraig wrotes: I wonder might we have a separate option, --suffix-start, and theoretically that could accept alphabetic options too? I'm not suggesting we do this, but it's worth discussion. That's was my first idea but since your first mail subject was split --numeric-suffixes=N I assumed that you already thought about it as a bad solution. Wrong assumption I guess. - Solution 2: Pádraig wrotes: Thinking a bit more about it, it's probably worth to split the short and long options. Have -d not take a param as before, and have --numeric-suffixes take an optional param. To do this, leave 'optional_argument' in the long_opts array, and just remove the :: from the getopts call. My vote is for solution 2. Less options = simpler interface for users. I don't think it's too onerous to mandate, numeric suffixes for this feature. Personally, I do prefer the Solution 1 since the result looks more consistent, more powerful andf does not change anything to the current options. However, it needs more work. cheers, Pádraig.
bug#6960: mv refuses to move a symlink over a hard link to the same file
On 01/30/2012 03:41 AM, Jim Meyering wrote: /* 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 1) src is a symlink, 2) dest is not a symlink, 3) dest has a link count of 2 or more and 4) 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. Note that technically, condition #4 obviates condition #2, but we retain the 1 st_nlink condition because that means fewer invocations of the more expensive #4. The last 3 lines are confusing. Don't you mean condition #3 and not condition #2? The last 2 lines talk about condition 3, not condition 2. Come to think of it, why is condition 2 needed at all? Can't we eliminate it, both in the commentary and in the code? If a symlink has a link count greater than 1, then overwriting it won't lose the link; in that sense it's just like a regular file with a link count greater than 1. So why are symlinks special there?
bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.
Pádraig wrotes:
On 01/30/2012 05:33 PM, Jérémy Compostella wrote:
Pádraig, Jim, others,
- Solution 1:
Pádraig wrotes:
I wonder might we have a separate option, --suffix-start, and
theoretically that could accept alphabetic options too? I'm not
suggesting we do this, but it's worth discussion.
That's was my first idea but since your first mail subject was split
--numeric-suffixes=N I assumed that you already thought about it as a
bad solution. Wrong assumption I guess.
- Solution 2:
Pádraig wrotes:
Thinking a bit more about it, it's probably worth to split the short
and long options. Have -d not take a param as before, and have
--numeric-suffixes take an optional param.
To do this, leave 'optional_argument' in the long_opts array, and just
remove the :: from the getopts call.
My vote is for solution 2.
Less options = simpler interface for users.
I don't think it's too onerous to mandate,
numeric suffixes for this feature.
OK, I attached the updated patch. If nobody does challenge the Solution
2 I think we have the appropriate implementation.
Note: I just received my coreutils assignment PDF file. I will print it
and send it this week.
Cheers,
Jeremy
---
From 79f08eef51b5651f153e0bacaab28c1da73c6517 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 option. If 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 |5 ++-
src/split.c| 60 +++
3 files changed, 64 insertions(+), 7 deletions(-)
diff --git a/NEWS b/NEWS
index 2b0926f..083e047 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 option. If 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..2d2ba32 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3084,10 +3084,11 @@ and so can be a pipe for example.
Use suffixes of length @var{length}. The default @var{length} is 2.
@item -d
-@itemx --numeric-suffixes
+@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..ca72637 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 unsigned long 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, --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 +
bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.
Pádraig Brady wrote: On 01/30/2012 05:33 PM, Jérémy Compostella wrote: Pádraig, Jim, others, - Solution 1: Pádraig wrotes: I wonder might we have a separate option, --suffix-start, and theoretically that could accept alphabetic options too? I'm not suggesting we do this, but it's worth discussion. That's was my first idea but since your first mail subject was split --numeric-suffixes=N I assumed that you already thought about it as a bad solution. Wrong assumption I guess. - Solution 2: Pádraig wrotes: Thinking a bit more about it, it's probably worth to split the short and long options. Have -d not take a param as before, and have --numeric-suffixes take an optional param. To do this, leave 'optional_argument' in the long_opts array, and just remove the :: from the getopts call. My vote is for solution 2. Less options = simpler interface for users. I don't think it's too onerous to mandate, numeric suffixes for this feature. Same here. Another reason to avoid adding --suffixanything is that it would invalidate -- rendering ambiguous -- any existing use of split that takes advantage of --suffix (or --s for that matter) being an abbreviation of the --suffix-length option name.
bug#9085: 'split' feature request: an option to uses e.g. '.001' as first suffix.
Pádraig Brady wrote: On 01/30/2012 05:33 PM, Jérémy Compostella wrote: Pádraig, Jim, others, - Solution 1: Pádraig wrotes: I wonder might we have a separate option, --suffix-start, and theoretically that could accept alphabetic options too? I'm not suggesting we do this, but it's worth discussion. That's was my first idea but since your first mail subject was split --numeric-suffixes=N I assumed that you already thought about it as a bad solution. Wrong assumption I guess. - Solution 2: Pádraig wrotes: Thinking a bit more about it, it's probably worth to split the short and long options. Have -d not take a param as before, and have --numeric-suffixes take an optional param. To do this, leave 'optional_argument' in the long_opts array, and just remove the :: from the getopts call. My vote is for solution 2. Less options = simpler interface for users. I don't think it's too onerous to mandate, numeric suffixes for this feature. Same here. Another reason to avoid adding --suffixanything is that it would invalidate -- rendering ambiguous -- any existing use of split that takes advantage of --suffix (or --s for that matter) being an abbreviation of the --suffix-length option name. OK I understand that too. However, IMHO it could be avoid with a not suffix prefixed option name, like --numeric-suffixes does in a sense, no ? Anyway, I'm completely new in its project so I learn from you. Cheers, Jeremy
bug#6960: mv refuses to move a symlink over a hard link to the same file
Paul Eggert wrote:
On 01/30/2012 03:41 AM, Jim Meyering wrote:
/* 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
1) src is a symlink,
2) dest is not a symlink,
3) dest has a link count of 2 or more and
4) 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.
Note that technically, condition #4 obviates condition #2, but we
retain the 1 st_nlink condition because that means fewer invocations
of the more expensive #4.
The last 3 lines are confusing.
Don't you mean condition #3 and not condition #2?
Good catch. You're right.
The last 2 lines talk about condition 3, not condition 2.
Come to think of it, why is condition 2 needed at all?
Another good catch. It's not needed.
Can't we eliminate it, both in the commentary and in the code?
If a symlink has a link count greater than 1, then overwriting
it won't lose the link; in that sense it's just like a regular
file with a link count greater than 1. So why are symlinks
special there?
Thanks for the review!
Adjusted via this:
diff --git a/src/copy.c b/src/copy.c
index 2c7582f..d66b0fc 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -1354,14 +1354,13 @@ same_file_ok (char const *src_name, struct stat const
*src_sb,
onto its referent, but in at least one narrow case, it is not:
In move mode, when
1) src is a symlink,
- 2) dest is not a symlink,
- 3) dest has a link count of 2 or more and
- 4) dest and the referent of src are not the same entry,
+ 2) dest has a link count of 2 or more and
+ 3) dest and the referent of src are not the same directory entry,
then it's ok, since while we'll lose one of those hard links,
src will still point to a remaining link.
- Note that technically, condition #4 obviates condition #2, but we
+ Note that technically, condition #3 obviates condition #2, but we
retain the 1 st_nlink condition because that means fewer invocations
- of the more expensive #4.
+ of the more expensive #3.
Given this,
$ touch f ln f l ln -s f s
@@ -1373,7 +1372,6 @@ same_file_ok (char const *src_name, struct stat const
*src_sb,
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);
bug#10472: `realpath --relative-to=path /` outputs inconsistent trailing slash
On 01/10/2012 01:15 PM, Mike Frysinger wrote: however, if the last argument is just the root path: realpath --relative-to=/usr / realpath --relative-to=/usr/ / we end up with a trailing slash: ../ for consistency, i don't think that should be the case (reported by Ulrich Müller via https://bugs.gentoo.org/398339) Another bug, on a system where // is distinct from /: $ realpath --relative-to=/ //machine / // /bin machine . . bin $ realpath --relative-to=// //machine / // /bin machine . . bin when it should really be: $ realpath --relative-to=/ //machine / // /bin //machine . // bin $ realpath --relative-to=// //machine / // /bin machine / . /bin We need to make realpath robust to correct leading // handling; I don't know if we should follow the lead of 'dirname' in only doing it on machines where // is special, or if it is easier to make it honor POSIX by special-casing // everywhere even on machines where / and // are identical. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#10472: `realpath --relative-to=path /` outputs inconsistent trailing slash
On 01/30/2012 09:10 PM, Eric Blake wrote: On 01/10/2012 01:15 PM, Mike Frysinger wrote: however, if the last argument is just the root path: realpath --relative-to=/usr / realpath --relative-to=/usr/ / we end up with a trailing slash: ../ for consistency, i don't think that should be the case (reported by Ulrich Müller via https://bugs.gentoo.org/398339) Another bug, on a system where // is distinct from /: $ realpath --relative-to=/ //machine / // /bin machine . . bin $ realpath --relative-to=// //machine / // /bin machine . . bin when it should really be: $ realpath --relative-to=/ //machine / // /bin //machine . // bin $ realpath --relative-to=// //machine / // /bin machine / . /bin We need to make realpath robust to correct leading // handling; I don't know if we should follow the lead of 'dirname' in only doing it on machines where // is special, or if it is easier to make it honor POSIX by special-casing // everywhere even on machines where / and // are identical. So on such a machine, I guess `readlink -m //machine/` outputs '//machine'. To match up with that, I think it makes sense to only do this on systems where a double slash is significant. BTW, this is how I'm interpreting this example: $ realpath --relative-to=// //machine / // /bin machine / . /bin I'm taking --relative-to=// to mean relative to the network. Hence relative output will be machines on the network, while absolute are local paths. gnulib says // matters for Apollo DomainOS (too old to port to), Cygwin, and z/OS. cheers, Pádraig.
bug#10472: `realpath --relative-to=path /` outputs inconsistent trailing slash
On 01/30/2012 03:01 PM, Pádraig Brady wrote: $ realpath --relative-to=// //machine / // /bin machine / . /bin We need to make realpath robust to correct leading // handling; I don't know if we should follow the lead of 'dirname' in only doing it on machines where // is special, or if it is easier to make it honor POSIX by special-casing // everywhere even on machines where / and // are identical. So on such a machine, I guess `readlink -m //machine/` outputs '//machine'. Correct. To match up with that, I think it makes sense to only do this on systems where a double slash is significant. I'm tending to agree - readlink, dirname, and realpath should all behave consistently within a single compilation of coreutils. BTW, this is how I'm interpreting this example: $ realpath --relative-to=// //machine / // /bin machine / . /bin I'm taking --relative-to=// to mean relative to the network. Hence relative output will be machines on the network, while absolute are local paths. Correct. Another bug still in the latest coreutils.git, but only on platforms with distinct //: $ src/realpath / // /// / // // Oops, that last line should be /. This bug is shared by readlink: $ src/readlink -m /// // gnulib says // matters for Apollo DomainOS (too old to port to), Cygwin, and z/OS. And I tested on Cygwin (if it wasn't obvious :) I can try to develop patches as part of porting coreutils 8.15 to cygwin (cygwin already has a realpath(1), but it is severely limited in that it only takes one file name and no command line options on what to do with that name; I'm pretty sure that the coreutils realpath is upwards compatible with the existing cygwin realpath: http://cygwin.com/ml/cygwin-apps/2012-01/msg00080.html). -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#10639: BUG REPORT coreutils-8.15 Solaris 10 64bit
On 01/29/2012 09:25 PM, JONES, BILL wrote: The FS are a mix. Some vxfs and some ufs. Thanks; which file system was the test actually run on? (I have a Solaris 10 sparc box here to test with, just wanna have something as close to yours as I can.)
bug#10472: `realpath --relative-to=path /` outputs inconsistent trailing slash
On 01/30/2012 10:22 PM, Eric Blake wrote: On 01/30/2012 03:01 PM, Pádraig Brady wrote: $ realpath --relative-to=// //machine / // /bin machine / . /bin We need to make realpath robust to correct leading // handling; I don't know if we should follow the lead of 'dirname' in only doing it on machines where // is special, or if it is easier to make it honor POSIX by special-casing // everywhere even on machines where / and // are identical. So on such a machine, I guess `readlink -m //machine/` outputs '//machine'. Correct. To match up with that, I think it makes sense to only do this on systems where a double slash is significant. I'm tending to agree - readlink, dirname, and realpath should all behave consistently within a single compilation of coreutils. BTW, this is how I'm interpreting this example: $ realpath --relative-to=// //machine / // /bin machine / . /bin I'm taking --relative-to=// to mean relative to the network. Hence relative output will be machines on the network, while absolute are local paths. Correct. Another bug still in the latest coreutils.git, but only on platforms with distinct //: $ src/realpath / // /// / // // Oops, that last line should be /. This bug is shared by readlink: $ src/readlink -m /// // The above will require a gnulib fix gnulib says // matters for Apollo DomainOS (too old to port to), Cygwin, and z/OS. And I tested on Cygwin (if it wasn't obvious :) I can try to develop patches as part of porting coreutils 8.15 to cygwin I'll take you up on that, thanks! (cygwin already has a realpath(1), but it is severely limited in that it only takes one file name and no command line options on what to do with that name; I'm pretty sure that the coreutils realpath is upwards compatible with the existing cygwin realpath: http://cygwin.com/ml/cygwin-apps/2012-01/msg00080.html). I had a look at the source, and it's just a simple wrapper around realpath(), that only accepts a single path. So coreutils realpath should be a drop in replacement. (wow it's hard to navigate cygwin stuff. It took me 3 mins to find the latest source). cheers, Pádraig.
bug#10639: BUG REPORT coreutils-8.15 Solaris 10 64bit
I am not sure how the test was run...if it was run in the current directory as the compile it would be /appl/... those are vxfs. Bill From: Paul Eggert [egg...@cs.ucla.edu] Sent: Monday, January 30, 2012 5:34 PM To: JONES, BILL Cc: 10...@debbugs.gnu.org Subject: Re: bug#10639: BUG REPORT coreutils-8.15 Solaris 10 64bit On 01/29/2012 09:25 PM, JONES, BILL wrote: The FS are a mix. Some vxfs and some ufs. Thanks; which file system was the test actually run on? (I have a Solaris 10 sparc box here to test with, just wanna have something as close to yours as I can.)
