GNU bug report logs - #43657
rm does not delete files

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 43657 in the body.
You can then email your comments to 43657 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: Amit Rao <amitrao17 <at> amitrao17.onmicrosoft.com>
To: "bug-coreutils <at> gnu.org" <bug-coreutils <at> gnu.org>
Subject: rm does not delete files
Date: Sun, 27 Sep 2020 20:00:43 +0000

rm /path/*

does not delete files if there are a lot (say 2000) of them in a single
directory

version is 8.32 on ubuntu 20.04

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: "amitrao17 <at> gmail.com" <amitrao17 <at> gmail.com>
Cc: 43657 <at> debbugs.gnu.org
Subject: Re: bug#43657: rm does not delete files
Date: Sun, 27 Sep 2020 15:54:19 -0700

On 9/27/20 1:00 PM, Amit Rao wrote:
> rm /path/*
> 
> does not delete files if there are a lot (say 2000) of them in a single
> directory

What does the command do instead?

There is a limit as to how many arguments you can pass to 'rm'. If that's what 
you ran into, it's a problem with your kernel or your shell, not with 'rm'.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Amit Rao <amitrao17 <at> amitrao17.onmicrosoft.com>
Cc: 43657 <at> debbugs.gnu.org
Subject: Re: bug#43657: rm does not delete files
Date: Mon, 28 Sep 2020 01:01:56 -0700

On 9/27/20 8:58 PM, Amit Rao wrote:
> There's a limit? My first attempt didn't use a wildcard; i attempted to delete a directory.

'rm dir' fails because 'rm' by default leaves directories alone.

> My second attempt was rm -rf dir/*

If "dir" has too many files that will fail due to shell limitations that have 
nothing to do with Coreutils. Use 'rm -rf dir' instead.

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

From: Bob Proulx <bob <at> proulx.com>
To: Amit Rao <amitrao17 <at> amitrao17.onmicrosoft.com>, 43657 <at> debbugs.gnu.org
Subject: Re: bug#43657: rm does not delete files
Date: Thu, 15 Oct 2020 22:18:12 -0600

close 43657
thanks

Paul Eggert wrote:
> On 9/27/20 8:58 PM, Amit Rao wrote:
> > There's a limit? My first attempt didn't use a wildcard; i attempted to delete a directory.
> 
> 'rm dir' fails because 'rm' by default leaves directories alone.
> 
> > My second attempt was rm -rf dir/*
> 
> If "dir" has too many files that will fail due to shell limitations that
> have nothing to do with Coreutils. Use 'rm -rf dir' instead.

The only reason I can guess that rm -rf dir/* might fail would be
argument list too long.  Which has an FAQ entry.  I feel confident
this was the problem you experienced.

    https://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Argument-list-too-long

In any case in order to establish the background it is necessary to
post command that you used exactly and then also the error message
that resulted.  Without that information exactly it is not possible to
establish the root cause of the behavior, if it is a bug, or if it is
kernel behavior.

Also if rm were to fail then extremely useful would be strace
information so that we could see the exact reason for the failure.

If this is the ARG_MAX limitation then it does not need rm to
reproduce the issue.  One can use any command.  Using echo should be
safe enough.

    echo dir/* >/dev/null

In any case the suggested strategy of using "rm -rf dir" is very good
and very simple here.  It avoids that problem entirely.

Because I feel very confident that the issue is the kernel limitation
of ARG_MAX I am going to close this ticket.  However if you have
further information please reply and add it to the ticket.  It can
always be opened again if further information points to a bug to be
tracked.

Bob

Previous Next

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