Jim Meyering wrote:
> Ladislav Hagara wrote:
>> the behaviour of rm from last stable coreutils 8.1 is quite different
>> from previous 7.6 one.
> ....
>> Is this a bug or a new feature of rm 8.1?
>
> Thank you very much for the report!
> That is most definitely a bug.
>
> The fix has two parts:
>
> in gnulib:
>
> The fts_open function in gnulib's fts module must not fail
> immediately upon spotting an empty string argument.
> That is the sole functional change. The rest is clean-up:
>
> in coreutils:
>
> rm: fix empty-name bug introduced with conversion to use fts
>
> While "rm ''" would properly fail, "rm F1 '' F2" would fail
> to remove F1 and F2, due to the empty string argument.
> This bug was introduced on 2009-07-12, via commit 4f73ecaf,
> "rm: rewrite to use fts".
> * NEWS (Bug fixes): Describe it.
> * tests/rm/empty-name: Adjust for changed diagnostic.
> (mk_file): Define, copied from misc/ls-misc.
> (empty-name-2): New test, for today's fix.
> * lib/xfts.c (xfts_open): Reflect the change in fts_open, now that
> it no longer fails immediately when one argument is the empty string.
> Assert that the bit flags were not the cause of failure.
> * po/POTFILES.in: Remove xfts.c.
> * THANKS: Update.
> Reported by Ladislav Hagara.
>
> I'll push something like the following today,
> once I've audited fts.c more closely to ensure
> that lifting the prohibition on empty names is ok.
I see no problem with zero-length names.
I suspect that the prohibition was to avoid the old SunOS4-era problem
whereby stat("",... would mistakenly succeed. With gnulib's stat*
replacements, that can't happen now.
Here's the slightly different patch for fts.c that I've just pushed:
>From cdfe647f8d29540cdfe90cef0fa568c5d2fd4481 Mon Sep 17 00:00:00 2001
From: Jim Meyering <meyer...@redhat.com>
Date: Tue, 1 Dec 2009 12:06:34 +0100
Subject: [PATCH] fts: fts_open: do not let an empty string cause immediate
failure
This is required in support of GNU rm, for which the command
"rm A '' B" must process and remove both A and B, in spite of
the empty string argument.
* lib/fts.c (fts_open): Do not let the presence of an empty string
cause fts_open to fail immediately. Most fts-using tools must be
able to process all arguments, in order, and can be expected to
diagnose such arguments themselves.
Also, move declaration of local, "len", "down" to initialization.
---
ChangeLog | 11 +++++++++++
lib/fts.c | 9 ++-------
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 07918de..6eec830 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2009-12-01 Jim Meyering <meyer...@redhat.com>
+
+ fts: fts_open: do not let an empty string cause immediate failure
+ This is required in support of GNU rm, for which the command
+ "rm A '' B" must process and remove both A and B, in spite of
+ the empty string argument.
+ * lib/fts.c (fts_open): Do not let the presence of an empty string
+ cause fts_open to fail immediately. Most fts-using tools must be
+ able to process all arguments, in order, and can be expected to
+ diagnose such arguments themselves.
+
2009-11-30 Eric Blake <e...@byu.net>
utimens: fix compilation error
diff --git a/lib/fts.c b/lib/fts.c
index 21c6658..39922b6 100644
--- a/lib/fts.c
+++ b/lib/fts.c
@@ -375,7 +375,6 @@ fts_open (char * const *argv,
register size_t nitems;
FTSENT *parent = NULL;
FTSENT *tmp = NULL; /* pacify gcc */
- size_t len;
bool defer_stat;
/* Options check. */
@@ -474,12 +473,8 @@ fts_open (char * const *argv,
/* Allocate/initialize root(s). */
for (root = NULL, nitems = 0; *argv != NULL; ++argv, ++nitems) {
- /* Don't allow zero-length file names. */
- if ((len = strlen(*argv)) == 0) {
- __set_errno (ENOENT);
- goto mem3;
- }
-
+ /* *Do* allow zero-length file names. */
+ size_t len = strlen(*argv);
if ((p = fts_alloc(sp, *argv, len)) == NULL)
goto mem3;
p->fts_level = FTS_ROOTLEVEL;
--
1.6.6.rc0.324.gb5bf2
