bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
On 09/04/2012 06:55 PM, Linda A. Walsh wrote: So how do delete all files in the directory without wild cards? Why tie your hands behind your back? Use wild cards: cd DIRECTORY rm -fr * .[!.] .??* If you do this a lot, put it into a shell script. It's not like the need is all that common, for most people, but if you need it that's what scripts are for. If you fiddle with your shell settings about how wildcards are expanded, make sure your script does wildcards in the standard way.
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
On 09/05/2012 08:25 AM, Paul Eggert wrote: On 09/04/2012 06:55 PM, Linda A. Walsh wrote: So how do delete all files in the directory without wild cards? Why tie your hands behind your back? Use wild cards: cd DIRECTORY rm -fr * .[!.] .??* If you do this a lot, put it into a shell script. It's not like the need is all that common, for most people, but if you need it that's what scripts are for. If you fiddle with your shell settings about how wildcards are expanded, make sure your script does wildcards in the standard way. Exactly, we're now at the point where globbing is the topic, much way away from coreutils and rm. Bash knows dotglob: $ mkdir d; cd d $ touch .a b ; mkdir c $ ( shopt -s dotglob ; rm -rv * ) removed `.a' removed `b' removed directory: `c' Have a nice day, Berny
bug#12350: Composites identified as primes in factor.c (when HAVE_GMP)
Eric Blake wrote: On 09/04/2012 10:42 AM, Jim Meyering wrote: Jim Meyering wrote: Torbjorn Granlund wrote: Problem numbers are of the for N=pq, p,q prime and (p-1)/(q-1) = s, s/for/form/ Fixed. Thanks.
bug#12350: Composites identified as primes in factor.c (when HAVE_GMP)
Torbjorn Granlund wrote: Jim Meyering j...@meyering.net writes: Jim Meyering wrote: Torbjorn Granlund wrote: The very old factoring code cut from an now obsolete version GMP does not pass proper arguments to the mpz_probab_prime_p function. It ask for 3 Miller-Rabin tests only, which is not sufficient. Hi Torbjorn Thank you for the patch and explanation. I've converted that into the commit below in your name. Please proofread it and let me know if you'd like to change anything. I tweaked the patch to change MR_REPS from a #define to an enum and to add the comment just preceding. I'll add NEWS and tests separately. ... From: Torbjorn Granlund t...@gmplib.org Date: Tue, 4 Sep 2012 16:22:47 +0200 Subject: [PATCH] factor: don't ever declare composites to be prime Torbjörn, I've just noticed that I misspelled your name above. Did you? I meant that I used Torbjorn rather than Torbjörn. Well, you misspell recognise too, but then again, most people on the other side of the pond misspell lots of English words. :-) Yes, the dichotomy is unfortunate. Over the years, it has even caused interface problems, i.e., with --colours vs --colors and $LS_COLOURS vs LS_COLORS. I wanted to settle on one, and US spelling is more common than British so I settled on that.
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
On 09/04/2012 11:58 PM, Linda A. Walsh wrote: I'm not talking for interactive use... I'm talking for use in a script that might run on systems that are not mine -- so I can't rely on shell settings. Yes you can. Just start the script with #!/bin/sh, as usual. When invoked that way, Bash and other shells are POSIX-compliant in this area.
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
Paul Eggert wrote: On 09/04/2012 11:58 PM, Linda A. Walsh wrote: I'm not talking for interactive use... I'm talking for use in a script that might run on systems that are not mine -- so I can't rely on shell settings. Yes you can. Just start the script with #!/bin/sh, as usual. When invoked that way, Bash and other shells are POSIX-compliant in this area. To what level of posix... if they are compliant to the original level then they might have the original behavior that allowed rm -r . to work. if they are the 2003 version, then a different way, .. bleh. I overly worry about things that don't occur, but get caught by things I didn't worry enough about. So it doesn't really matter. I just preferred simplicity to the ever changing posix.
bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.
Jim Meyering wrote:
...
I'll post this new pair of rm-related patches in a minute.
Here's what I'm ready to push.
Finally, I'm not adding a test for what happens
when one tries to run rm -r s/ (with s being a symlink),
since that is so system-specific. I suppose I could add
test solely to ensure that if it fails, it does not fail
with the ELOOP message, but that seems way too weak.
From 57dd06703cb89ba53d05af95c11e89a2ca51af5c Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Tue, 4 Sep 2012 14:40:11 +0200
Subject: [PATCH 1/2] rm: avoid bogus diagnostic for a slash-decorated
symlink-to-dir
These commands would evoke an invalid diagnostic:
$ mkdir d ln -s d s env rm -r s/
rm: cannot remove 's': Too many levels of symbolic links
remove.c was stripping trailing slashes from s/ before passing
the name to rm. But a trailing slash may change the semantics,
and thus should not be stripped.
* src/remove.c (rm_fts): Do not strip trailing slashes.
* tests/rm/v-slash.sh: Adapt to new expected output.
* gnulib: Update to latest, for an improved fts.c that merely
normalizes trailing slashes.
Reported by Paul Eggert in discussion of http://bugs.gnu.org/12339
---
NEWS| 4
gnulib | 2 +-
src/remove.c| 3 ---
tests/rm/v-slash.sh | 2 +-
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/NEWS b/NEWS
index f3874fd..a848ffe 100644
--- a/NEWS
+++ b/NEWS
@@ -19,6 +19,10 @@ GNU coreutils NEWS-*-
outline -*-
than ignoring the -d option and failing with an 'Is a directory' error.
[bug introduced in coreutils-8.19, with the addition of --dir (-d)]
+ rm -r S/ (where S is a symlink-to-directory) no longer gives the invalid
+ Too many levels of symbolic links diagnostic.
+ [bug introduced in coreutils-8.6]
+
** Improvements
stat and tail work better with ZFS. stat -f --format=%T now reports the
diff --git a/gnulib b/gnulib
index 68f693f..3a9002d 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit 68f693ff1db33bf24695f0f42c62e7801966fd06
+Subproject commit 3a9002d3cc63da7110f133b1040d2d2b0aad8305
diff --git a/src/remove.c b/src/remove.c
index 69faae6..847a5cc 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -433,9 +433,6 @@ rm_fts (FTS *fts, FTSENT *ent, struct rm_options const *x)
/* Perform checks that can apply only for command-line arguments. */
if (ent-fts_level == FTS_ROOTLEVEL)
{
- if (strip_trailing_slashes (ent-fts_path))
-ent-fts_pathlen = strlen (ent-fts_path);
-
/* If the basename of a command line argument is . or ..,
diagnose it and do nothing more with that argument. */
if (dot_or_dotdot (last_component (ent-fts_accpath)))
diff --git a/tests/rm/v-slash.sh b/tests/rm/v-slash.sh
index 504f4ff..ec77bd0 100755
--- a/tests/rm/v-slash.sh
+++ b/tests/rm/v-slash.sh
@@ -26,7 +26,7 @@ touch a/x || framework_failure_
rm --verbose -r a/// out || fail=1
cat \EOF exp || fail=1
removed 'a/x'
-removed directory: 'a'
+removed directory: 'a/'
EOF
compare exp out || fail=1
--
1.7.12.176.g3fc0e4c
From eda8c84778bc72192592b79724466946ca7def97 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Wed, 5 Sep 2012 16:48:50 +0200
Subject: [PATCH 2/2] rm: be more careful when using a replacement errno value
* src/remove.c (excise): Tighten the test for when we defer to an
old errno value: instead of relying solely on an FTS_DNR (unreadable
directory) failure, also test current and replacement errno values.
This change would also have solved the problem addressed by commit
v8.19-106-g57dd067. For more info, see http://bugs.gnu.org/12339#113
---
gnulib | 2 +-
src/remove.c | 12 +++-
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/gnulib b/gnulib
index 3a9002d..68f693f 16
--- a/gnulib
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit 3a9002d3cc63da7110f133b1040d2d2b0aad8305
+Subproject commit 68f693ff1db33bf24695f0f42c62e7801966fd06
diff --git a/src/remove.c b/src/remove.c
index 847a5cc..0c25462 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -392,11 +392,13 @@ excise (FTS *fts, FTSENT *ent, struct rm_options const
*x, bool is_dir)
if (ignorable_missing (x, errno))
return RM_OK;
- /* When failing to rmdir an unreadable directory, the typical
- errno value is EISDIR, but that is not as useful to the user
- as the errno value from the failed open (probably EPERM).
- Use the earlier, more descriptive errno value. */
- if (ent-fts_info == FTS_DNR)
+ /* When failing to rmdir an unreadable directory, the typical errno value
+ is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic.
+ When that happens and the errno value from the failed open is EPERM
+ or EACCES, use the earlier, more descriptive errno value. */
+ if (ent-fts_info == FTS_DNR
+ (errno == ENOTEMPTY || errno == EISDIR || errno == ENOTDIR)
+
bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.
On 09/05/2012 07:56 AM, Jim Meyering wrote: + /* When failing to rmdir an unreadable directory, the typical errno value + is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic. + When that happens and the errno value from the failed open is EPERM + or EACCES, use the earlier, more descriptive errno value. */ + if (ent-fts_info == FTS_DNR + (errno == ENOTEMPTY || errno == EISDIR || errno == ENOTDIR) + (ent-fts_errno == EPERM || ent-fts_errno == EACCES)) Thanks for doing all that. I did notice that the code mentions ENOTEMPTY but the comment doesn't -- is that intentional?
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
On 09/05/2012 07:51 AM, Linda A. Walsh wrote: Just start the script with #!/bin/sh, as usual. When invoked that way, Bash and other shells are POSIX-compliant in this area. To what level of posix... To all the levels that are relevant for this discussion. In practice, people use #!/bin/sh and it works pretty well to avoid compatibility issues like this. It's not perfect for all POSIX issues, but you were asking for a solution to a particular problem, and this should solve your problem.
bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.
Paul Eggert wrote: On 09/05/2012 07:56 AM, Jim Meyering wrote: + /* When failing to rmdir an unreadable directory, the typical errno value + is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic. + When that happens and the errno value from the failed open is EPERM + or EACCES, use the earlier, more descriptive errno value. */ + if (ent-fts_info == FTS_DNR + (errno == ENOTEMPTY || errno == EISDIR || errno == ENOTDIR) + (ent-fts_errno == EPERM || ent-fts_errno == EACCES)) Thanks for doing all that. I did notice that the code mentions ENOTEMPTY but the comment doesn't -- is that intentional? Yes. I considered whether to remove explicit mention of those errno values in the comment for precisely that reason, but didn't bother. Good point. I've relaxed the comment wording enough to permit other explicit E* names: diff --git a/src/remove.c b/src/remove.c index 0c25462..a141718 100644 --- a/src/remove.c +++ b/src/remove.c @@ -392,8 +392,8 @@ excise (FTS *fts, FTSENT *ent, struct rm_options const *x, bool is_dir) if (ignorable_missing (x, errno)) return RM_OK; - /* When failing to rmdir an unreadable directory, the typical errno value - is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic. + /* When failing to rmdir an unreadable directory, we see errno values + like EISDIR or ENOTDIR, but they would be meaningless in a diagnostic. When that happens and the errno value from the failed open is EPERM or EACCES, use the earlier, more descriptive errno value. */ if (ent-fts_info == FTS_DNR
bug#12356: tail doesn't know vzfs
tail: unrecognized file system type 0x565a4653 for ‘/var/log/messages’. please report this to bug-coreutils@gnu.org. reverting to polling # mount /dev/vzfs on / type vzfs (rw,relatime) This is a container running on Parallels Virtuozzo 4.6, might also affect OpenVZ. Yours, Jens
bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.
Jim Meyering wrote: Paul Eggert wrote: On 09/05/2012 07:56 AM, Jim Meyering wrote: + /* When failing to rmdir an unreadable directory, the typical errno value + is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic. + When that happens and the errno value from the failed open is EPERM + or EACCES, use the earlier, more descriptive errno value. */ + if (ent-fts_info == FTS_DNR + (errno == ENOTEMPTY || errno == EISDIR || errno == ENOTDIR) + (ent-fts_errno == EPERM || ent-fts_errno == EACCES)) Thanks for doing all that. I did notice that the code mentions ENOTEMPTY but the comment doesn't -- is that intentional? Yes. I considered whether to remove explicit mention of those errno values in the comment for precisely that reason, but didn't bother. Good point. I've relaxed the comment wording enough to permit other explicit E* names: diff --git a/src/remove.c b/src/remove.c index 0c25462..a141718 100644 --- a/src/remove.c +++ b/src/remove.c @@ -392,8 +392,8 @@ excise (FTS *fts, FTSENT *ent, struct rm_options const *x, bool is_dir) if (ignorable_missing (x, errno)) return RM_OK; - /* When failing to rmdir an unreadable directory, the typical errno value - is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic. + /* When failing to rmdir an unreadable directory, we see errno values + like EISDIR or ENOTDIR, but they would be meaningless in a diagnostic. When that happens and the errno value from the failed open is EPERM or EACCES, use the earlier, more descriptive errno value. */ if (ent-fts_info == FTS_DNR I've pushed the result: http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=ccbd3f3b290cb1bb http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=57dd06703cb89ba5
bug#12356: tail doesn't know vzfs
Jens Rosenboom wrote: tail: unrecognized file system type 0x565a4653 for ‘/var/log/messages’. please report this to bug-coreutils@gnu.org. reverting to polling # mount /dev/vzfs on / type vzfs (rw,relatime) This is a container running on Parallels Virtuozzo 4.6, might also affect OpenVZ. Thanks for the report. This should fix it: (marking done so I don't forget -- comments will still show up and you're welcome to reopen, if desired) From 38c5e7d12151d7673c4118668eb43b24643e10da Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Wed, 5 Sep 2012 22:33:44 +0200 Subject: [PATCH] tail,stat: add support for VZFS * src/stat.c (human_fstype): Add a case: vzfs, 0x565A4653 (local). Reported by Jens Rosenboom in http://bugs.gnu.org/12356 --- src/stat.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/stat.c b/src/stat.c index f75b7af..a9fb951 100644 --- a/src/stat.c +++ b/src/stat.c @@ -415,6 +415,8 @@ human_fstype (STRUCT_STATVFS const *statfsbuf) return v9fs; case S_MAGIC_VXFS: /* 0xA501FCF5 local */ return vxfs; +case S_MAGIC_VZFS: /* 0x565A4653 local */ + return vzfs; case S_MAGIC_XENFS: /* 0xABBA1974 local */ return xenfs; case S_MAGIC_XENIX: /* 0x012FF7B4 local */ -- 1.7.12.176.g3fc0e4c
bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.
Thanks for the efforts at cleaning things up...it's appreciated even if it's not exactly what I might want...just wanted to emphasize that your I appreciate the work you are doing!.. I just don't always appreciate the 'posixifing' of linux's default behavior...but then I like powerful interface that allow me to shoot myself in the foot if I really want to! ;-) Jim Meyering wrote: Paul Eggert wrote: On 09/05/2012 07:56 AM, Jim Meyering wrote: + /* When failing to rmdir an unreadable directory, the typical errno value + is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic. + When that happens and the errno value from the failed open is EPERM + or EACCES, use the earlier, more descriptive errno value. */ + if (ent-fts_info == FTS_DNR + (errno == ENOTEMPTY || errno == EISDIR || errno == ENOTDIR) + (ent-fts_errno == EPERM || ent-fts_errno == EACCES)) Thanks for doing all that. I did notice that the code mentions ENOTEMPTY but the comment doesn't -- is that intentional? Yes. I considered whether to remove explicit mention of those errno values in the comment for precisely that reason, but didn't bother. Good point. I've relaxed the comment wording enough to permit other explicit E* names: diff --git a/src/remove.c b/src/remove.c index 0c25462..a141718 100644 --- a/src/remove.c +++ b/src/remove.c @@ -392,8 +392,8 @@ excise (FTS *fts, FTSENT *ent, struct rm_options const *x, bool is_dir) if (ignorable_missing (x, errno)) return RM_OK; - /* When failing to rmdir an unreadable directory, the typical errno value - is EISDIR or ENOTDIR, but that would be meaningless in a diagnostic. + /* When failing to rmdir an unreadable directory, we see errno values + like EISDIR or ENOTDIR, but they would be meaningless in a diagnostic. When that happens and the errno value from the failed open is EPERM or EACCES, use the earlier, more descriptive errno value. */ if (ent-fts_info == FTS_DNR
bug#12339: [PATCH] rm: avoid bogus diagnostic for a slash-decorated symlink-to-dir
Paul Eggert wrote: On 09/05/2012 07:51 AM, Linda A. Walsh wrote: Just start the script with #!/bin/sh, as usual. When invoked that way, Bash and other shells are POSIX-compliant in this area. To what level of posix... To all the levels that are relevant for this discussion. In practice, people use #!/bin/sh and it works pretty well to avoid compatibility issues like this. It's not perfect for all POSIX issues, but you were asking for a solution to a particular problem, and this should solve your problem. - Now I remember how I got here in the first place... It was because of bash moving to the POSIX 2003 standard and breaking many things I'd come to rely on, that I eventually realized that it was unsuitable to rely on for programming. I had written a logical volume snapshot generator and manager in about ~1500 lines of shell script across multiple files -- mostly as a proof of concept -- but also because it seemed simple and grew as I realized it was 90% error condition handling. Bash got very unreliable in handling error conditions via -e w/the new POSIX standard -- can't return non zero from a function (so no more mathematical functions), can't return non-zero from a calc (()) or let statement -- both of which now trigger error exits under -e due to POSIX More stuff happened, I decided to throw it away and rewrite in perl. I'm still wanting to call rm -fr without wild cards to remove everything in a directory. One would think the rm utility which is *designed* to remove files recursively, would do the task and NOT need the shell to do it's job. My perl program has tried to call rm -fr . and *, neither of which work. if rm can't remove all the files in a dir by itself -- I assert it is failing it's job as an 'rm' program. Removing files is it's sole job in life... it can remove singles and directories... using rm -fr ./. or dir/. or . were all ways of removing all contents under their targets without removing the directory. That feature is now gone. So I'd like to request it be added when not operating under POSIX_CORRECTLY. It's the right thing to do for the command line. We don't have so many clueless dweebs in a tty window -- most want point and click. I know I don't want to call bash as a helper for rm -- as I know with BASH_ENV, and such, it can very easily be running alot of overhead code besides the simple rm function I wanted to do. I think on many systems /bin/sh is a link to ash or dash, and no telling how they will act/perform -- I don't want an extra dependency. So should I start looking to write a patch for rm and possibly fork it? Just realizing that I'm where I'm at today because of bash going POSIX has left me pretty cold.
bug#12339: Bug: rm -fr . doesn't dir depth first deletion yet it is documented to do so.
This doesn't check POSIX_CORRECTLY, but it does fix the reported problem
rm -fr in . removes all files and leaves the dir:
Ishtar:/tmp/ttt touch one two three
Ishtar:/tmp/ttt cd ..
Ishtar:/tmp rm -fr ttt/.
Ishtar:/tmp ll ttt
total 0
---
Also works cd'd into the dir and doing an rm -fr .
I'll be happy to put in the check for POSIX_CORRECTLY if you are amenable...
Note.. am not claiming this is the most efficient way to do it, but it
seemed to be the least impact on code I was new to.
Ishtar:packages/sources/coreutils-8.14 cat coreutils-8.14.remove.c.diff
--- src/remove.c2011-10-10 00:56:46.0 -0700
+++ src/remove.c2012-09-05 18:23:58.449319142 -0700
@@ -446,6 +446,20 @@
return RM_ERROR;
}
+
+static inline bool
+dotdot (char const *file_name)
+{
+ if (file_name[0] == '.' file_name[1])
+{
+ char sep = file_name[(file_name[1] == '.') + 1];
+ return (! sep || ISSLASH (sep));
+}
+ else
+return false;
+}
+
+
/* This function is called once for every file system object that fts
encounters. fts performs a depth-first traversal.
A directory is usually processed twice, first with fts_info == FTS_D,
@@ -476,7 +490,7 @@
/* If the basename of a command line argument is . or ..,
diagnose it and do nothing more with that argument. */
- if (dot_or_dotdot (last_component (ent-fts_accpath)))
+ if (dotdot (last_component (ent-fts_accpath)))
{
error (0, 0, _(cannot remove directory: %s),
quote (ent-fts_path));
