GNU bug report logs - #7823
Rm -f fails on non-existant file

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7823 in the body.
You can then email your comments to 7823 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Nadav Har'El" <nyh <at> math.technion.ac.il>
To: bug-coreutils <at> gnu.org
Cc: ramic <at> il.ibm.com
Subject: Rm -f fails on non-existant file
Date: Tue, 11 Jan 2011 14:58:43 +0200

Hi,

"rm -f" is supposed to succeed (and not print an error message) when the
given file name does not exist.

Unfortunately, I found a rare case where this is not happening.

It appears that when mounting a Windows filesystem using Samba, if I try
running:
command

	#!/bin/sh
	mkdir emptydir
	rm -f emptydir/*

The shell leaves this "*" unchanged, and rm gives this name to unlink(2),
which oddly enough returns EINVAL (invalid argument) instead of the expected
ENOENT (no such file or directory!).

I'm guessing the smbfs people chose to give this as a special error when
"invalid" characters are used in the file name (this is a concept that doesn't
exist in Unix), but I'm not sure why it was so important to them to not
just return ENOENT in this case... But still, I think "rm" should behave
well in this case.

So currently, in the above example "rm -f emptydir/*", instead of just doing
nothing silently, prints an error message (Invalid Argument) and does exit(1).
This, for example, causes problems in Makefiles which run "rm -f" assuming it
won't fail (yes, I know, make has the "-" modifier - unfortunately some
makefiles don't use it...).

Anyway, in remove.c, you have

static inline bool
nonexistent_file_errno (int errnum)
{
  switch (errnum)
    {
    case ENOENT:
    case ENOTDIR:
      return true;
    default:
      return false;
    }
}

And I wonder whether EINVAL shouldn't also be added to it.

Thanks,
Nadav Har'El.

-- 
Nadav Har'El                        |      Tuesday, Jan 11 2011, 6 Shevat 5771
nyh <at> math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Share your knowledge. It's a way to
http://nadav.harel.org.il           |achieve immortality.

Message #8 received at 7823 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: "Nadav Har'El" <nyh <at> math.technion.ac.il>
Cc: 7823 <at> debbugs.gnu.org, ramic <at> il.ibm.com
Subject: Re: bug#7823: Rm -f fails on non-existant file
Date: Tue, 11 Jan 2011 07:56:31 -0700

[Message part 1 (text/plain, inline)]

On 01/11/2011 05:58 AM, Nadav Har'El wrote:
> Unfortunately, I found a rare case where this is not happening.
> 
> It appears that when mounting a Windows filesystem using Samba, if I try
> running:
> command
> 
> 	#!/bin/sh
> 	mkdir emptydir
> 	rm -f emptydir/*
> 
> The shell leaves this "*" unchanged, and rm gives this name to unlink(2),
> which oddly enough returns EINVAL (invalid argument) instead of the expected
> ENOENT (no such file or directory!).

Thanks for tracking this down.

> 
> I'm guessing the smbfs people chose to give this as a special error when
> "invalid" characters are used in the file name (this is a concept that doesn't
> exist in Unix), but I'm not sure why it was so important to them to not
> just return ENOENT in this case... But still, I think "rm" should behave
> well in this case.

Feel free to file a bug report to the smbfs people.  POSIX does not
specify EINVAL (except for bad flags to unlinkat), but does have a
global clause that states that any errno not specifically listed may be
returned if it is a better fit than any mandated error.  On the other
hand, the next version of POSIX will be mandating that the case of an
unsupported byte in a filename ('*' in the case of smbfs) shall fail
with EILSEQ, not EINVAL (that is, if they don't return the equally valid
ENOENT failure).  See http://austingroupbugs.net/view.php?id=293, for
justification why smbfs ought to change their errno value away from EINVAL.

> Anyway, in remove.c, you have
> 
> static inline bool
> nonexistent_file_errno (int errnum)
> {
>   switch (errnum)
>     {
>     case ENOENT:
>     case ENOTDIR:
>       return true;
>     default:
>       return false;
>     }
> }
> 
> And I wonder whether EINVAL shouldn't also be added to it.

Yes, since POSIX doesn't specify EINVAL for any other situation, I see
no harm in globally exempting it (with a comment why) in our source
code; likewise, I see no problem in also adding EILSEQ to that list,
whether or not smbfs also fixes their bug.

Is it okay if I push this patch in your name?

From 3201907296fd18084b68f062709d589c18e3ffe6 Mon Sep 17 00:00:00 2001
From: Nadav Har'El <nyh AT math.technion.ac.il>
Date: Tue, 11 Jan 2011 07:53:07 -0700
Subject: [PATCH] rm: ignore errno related to invalid file names

* src/remove.c (nonexistent_file_errno): Also skip EINVAL and
EILSEQ, for at least smbfs rejection of '*' in file names.
---
 src/remove.c |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/src/remove.c b/src/remove.c
index f7b00c6..3814232 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -378,10 +378,18 @@ nonexistent_file_errno (int errnum)
      exist, but be (in)accessible only via too long a symlink chain.
      Likewise for ENAMETOOLONG, since rm -f ./././.../foo may fail
      if the "..." part expands to a long enough sequence of "./"s,
-     even though ./foo does indeed exist.  */
+     even though ./foo does indeed exist.
+
+     Another case to consider is when a particular name is invalid for
+     a given file system.  In 2011, smbfs returns EINVAL, but the next
+     revision of POSIX will require EILSEQ for that situation:
+     http://austingroupbugs.net/view.php?id=293
+  */

   switch (errnum)
     {
+    case EILSEQ:
+    case EINVAL:
     case ENOENT:
     case ENOTDIR:
       return true;
-- 
1.7.3.4



-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #11 received at 7823 <at> debbugs.gnu.org (full text, mbox):

From: "Nadav Har'El" <nyh <at> math.technion.ac.il>
To: Eric Blake <eblake <at> redhat.com>
Cc: 7823 <at> debbugs.gnu.org, ramic <at> il.ibm.com
Subject: Re: bug#7823: Rm -f fails on non-existant file
Date: Tue, 11 Jan 2011 17:12:34 +0200

On Tue, Jan 11, 2011, Eric Blake wrote about "Re: bug#7823: Rm -f fails on non-existant file":
> Feel free to file a bug report to the smbfs people.  POSIX does not
> specify EINVAL (except for bad flags to unlinkat), but does have a
> global clause that states that any errno not specifically listed may be
> returned if it is a better fit than any mandated error.  On the other
> hand, the next version of POSIX will be mandating that the case of an
> unsupported byte in a filename ('*' in the case of smbfs) shall fail
> with EILSEQ, not EINVAL (that is, if they don't return the equally valid
> ENOENT failure).  See http://austingroupbugs.net/view.php?id=293, for
> justification why smbfs ought to change their errno value away from EINVAL.

Thanks, I'll look at how to send them a bug report as well.

> Yes, since POSIX doesn't specify EINVAL for any other situation, I see
> no harm in globally exempting it (with a comment why) in our source
> code; likewise, I see no problem in also adding EILSEQ to that list,
> whether or not smbfs also fixes their bug.
> 
> Is it okay if I push this patch in your name?

Yes, looks good. Thanks.

Nadav.

-- 
Nadav Har'El                        |      Tuesday, Jan 11 2011, 6 Shevat 5771
nyh <at> math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |"A mathematician is a device for turning
http://nadav.harel.org.il           |coffee into theorems" -- P. Erdos

Message #14 received at 7823 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: "Nadav Har'El" <nyh <at> math.technion.ac.il>
Cc: 7823 <at> debbugs.gnu.org, ramic <at> il.ibm.com
Subject: Re: bug#7823: Rm -f fails on non-existant file
Date: Tue, 11 Jan 2011 11:50:14 -0700

[Message part 1 (text/plain, inline)]

On 01/11/2011 08:12 AM, Nadav Har'El wrote:
> On Tue, Jan 11, 2011, Eric Blake wrote about "Re: bug#7823: Rm -f fails on non-existant file":
>> Feel free to file a bug report to the smbfs people.  POSIX does not
>> specify EINVAL (except for bad flags to unlinkat), but does have a
>> global clause that states that any errno not specifically listed may be
>> returned if it is a better fit than any mandated error.  On the other
>> hand, the next version of POSIX will be mandating that the case of an
>> unsupported byte in a filename ('*' in the case of smbfs) shall fail
>> with EILSEQ, not EINVAL (that is, if they don't return the equally valid
>> ENOENT failure).  See http://austingroupbugs.net/view.php?id=293, for
>> justification why smbfs ought to change their errno value away from EINVAL.
> 
> Thanks, I'll look at how to send them a bug report as well.
> 
>> Yes, since POSIX doesn't specify EINVAL for any other situation, I see
>> no harm in globally exempting it (with a comment why) in our source
>> code; likewise, I see no problem in also adding EILSEQ to that list,
>> whether or not smbfs also fixes their bug.
>>
>> Is it okay if I push this patch in your name?
> 
> Yes, looks good. Thanks.

Actually, this is a bug fix, so I'm also squashing this NEWS blurb in,
then pushing:

diff --git i/NEWS w/NEWS
index 5a70243..9ccad63 100644
--- i/NEWS
+++ w/NEWS
@@ -10,6 +10,9 @@ GNU coreutils NEWS
-*- outline -*-
   argument following the one containing the moved sub-tree.
   [bug introduced in coreutils-5.1.0]

+  rm -f no longer fails for EINVAL or EILSEQ on file systems that
+  reject file names invalid for that file system.
+

 * Noteworthy changes in release 8.9 (2011-01-04) [stable]


-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Message #17 received at 7823 <at> debbugs.gnu.org (full text, mbox):

From: "Nadav Har'El" <nyh <at> math.technion.ac.il>
To: Eric Blake <eblake <at> redhat.com>
Cc: 7823 <at> debbugs.gnu.org, ramic <at> il.ibm.com
Subject: Re: bug#7823: Rm -f fails on non-existant file
Date: Tue, 11 Jan 2011 23:20:28 +0200

On Tue, Jan 11, 2011, Eric Blake wrote about "Re: bug#7823: Rm -f fails on non-existant file":
> Actually, this is a bug fix, so I'm also squashing this NEWS blurb in,
> then pushing:

Thanks.

I also sent a bug report to the Samba guys. Let's see what they decide to
do about it:

	https://bugzilla.samba.org/show_bug.cgi?id=7907



-- 
Nadav Har'El                        |      Tuesday, Jan 11 2011, 7 Shevat 5771
nyh <at> math.technion.ac.il             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |"[I'm] so full of action, my name should
http://nadav.harel.org.il           |be a verb" -- Big Daddy Kane ("Raw", 1987)

Message #22 received at 7823-done <at> debbugs.gnu.org (full text, mbox):

From: Jim Meyering <jim <at> meyering.net>
To: Eric Blake <eblake <at> redhat.com>
Cc: ramic <at> il.ibm.com, Nadav Har'El <nyh <at> math.technion.ac.il>,
	7823-done <at> debbugs.gnu.org
Subject: Re: bug#7823: Rm -f fails on non-existant file
Date: Wed, 12 Jan 2011 06:34:54 +0100

Eric Blake wrote:
...
> Actually, this is a bug fix, so I'm also squashing this NEWS blurb in,
> then pushing:
>
> diff --git i/NEWS w/NEWS
...
> +  rm -f no longer fails for EINVAL or EILSEQ on file systems that
> +  reject file names invalid for that file system.

Thanks to both of you.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.