GNU bug report logs - #9950
rm -r partial failure

Previous Next

Package: coreutils;

Reported by: Graham Lawrence <gl00637 <at> gmail.com>

Date: Fri, 4 Nov 2011 16:20:01 UTC

Severity: normal

Tags: notabug

Done: Bob Proulx <bob <at> proulx.com>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#9950; Package coreutils. (Fri, 04 Nov 2011 16:20:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Graham Lawrence <gl00637 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Fri, 04 Nov 2011 16:20:02 GMT) Full text and rfc822 format available.

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

From: Graham Lawrence <gl00637 <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: rm -r partial failure
Date: Fri, 4 Nov 2011 07:52:40 -0700
By my understanding of rm -r the files listed by find below should
have been removed by the first rm.  But it took only some of them.
Vim was not running during this process.

~ $pwd
/home/g
~ $find /home -name *swp
/home/g/.vim/config.swp
/home/g/.vim/Notes.swp
/home/g/.vim/nzb.sh.swp
/home/g/.vim/makesess.vim.swp
/home/g/.vim/backup.sh.swp
/home/g/.vim/.vimrc.swp
/home/g/.vim/.bashrc.swp
/home/g/.vim/renamer.sh.swp
/home/g/.vim/vimcht.swp
/home/g/.vim/grepnotes.sh.swp
/home/g/Scripts/.reseq.awk.swp
/home/g/.fluxbox/.menu.swp
~ $rm -rf *.swp
~ $find /home -name *swp
/home/g/.vim/Notes.swp
/home/g/.vim/backup.sh.swp
/home/g/.vim/.vimrc.swp
/home/g/Scripts/.reseq.awk.swp
/home/g/.fluxbox/.menu.swp
~ $rm -rf *swp
~ $find /home -name *swp
/home/g/.vim/Notes.swp
/home/g/.vim/backup.sh.swp
/home/g/.vim/.vimrc.swp
/home/g/Scripts/.reseq.awk.swp
/home/g/.fluxbox/.menu.swp
~ $rm -f /home/g/.vim/Notes.swp
~ $rm /home/g/.vim/backup.sh.swp
~ $rm /home/g/.vim/.vimrc.swp
~ $rm /home/g/Scripts/.reseq.awk.swp
~ $rm /home/g/.fluxbox/.menu.swp
~ $find /home -name *swp
~ $




Added tag(s) notabug. Request was from Bob Proulx <bob <at> proulx.com> to control <at> debbugs.gnu.org. (Fri, 04 Nov 2011 16:36:02 GMT) Full text and rfc822 format available.

Reply sent to Bob Proulx <bob <at> proulx.com>:
You have taken responsibility. (Fri, 04 Nov 2011 16:36:02 GMT) Full text and rfc822 format available.

Notification sent to Graham Lawrence <gl00637 <at> gmail.com>:
bug acknowledged by developer. (Fri, 04 Nov 2011 16:36:02 GMT) Full text and rfc822 format available.

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

From: Bob Proulx <bob <at> proulx.com>
To: Graham Lawrence <gl00637 <at> gmail.com>
Cc: 9950-done <at> debbugs.gnu.org
Subject: Re: bug#9950: rm -r partial failure
Date: Fri, 4 Nov 2011 10:32:40 -0600
tags 9950 + notabug
thanks

Graham Lawrence wrote:
> By my understanding of rm -r the files listed by find below should
> have been removed by the first rm.  But it took only some of them.
> Vim was not running during this process.

Thank you for your bug report.  However this is simply a
misunderstanding of the shell file glob expansion of your shell and
not a bug in rm.

> ~ $pwd
> /home/g

You are in your home directory.

> ~ $find /home -name *swp
> /home/g/.vim/config.swp
> /home/g/.vim/Notes.swp
> /home/g/.vim/nzb.sh.swp
> /home/g/.vim/makesess.vim.swp
> /home/g/.vim/backup.sh.swp
> /home/g/.vim/.vimrc.swp
> /home/g/.vim/.bashrc.swp
> /home/g/.vim/renamer.sh.swp
> /home/g/.vim/vimcht.swp
> /home/g/.vim/grepnotes.sh.swp
> /home/g/Scripts/.reseq.awk.swp
> /home/g/.fluxbox/.menu.swp

There are twelve .swp files in subdirectories.  There are none in the
current directory.

> ~ $rm -rf *.swp

That will not match any files.  No files will be deleted.

You can verify that no files are matched by using the 'echo' command.
I will assume 'bash' for the following examples.

  $ echo ls -ldog *.swp
  ls -ldog *.swp

See?  No files are matched by the "*.swp" file glob.  The shell could
not find any and so the option argument was left unchanged.  If it had
matched files then the actual files would have been replaced on that
option argument.  For example:

  $ touch file1.test
  $ echo ls -ldog *.test
  ls -ldog file1.test

See how the file glob is replaced *by the shell* with the matching
files.  At this point your problem should be clear.  The file glob is
not matching any files and therefore rm isn't removing any.  rm isn't
complaining because the rm -f option tells it not to complain about
files that do not exist.  The string "*.swp" is a file that does not
exist.

> ~ $rm -f /home/g/.vim/Notes.swp
> ~ $rm /home/g/.vim/backup.sh.swp
> ~ $rm /home/g/.vim/.vimrc.swp
> ~ $rm /home/g/Scripts/.reseq.awk.swp
> ~ $rm /home/g/.fluxbox/.menu.swp
> ~ $find /home -name *swp
> ~ $

Right.  Here you have told rm to remove the files individually.  So of
course that works.

If you want to find files and then remove them you should use find.
And you are *already* using find.  So this should be natural.

  $ find /home -name '*.swp' -ls
  ...verify your file list...

  $ find /home -name '*.swp' -delete

Using -delete is a new option.  The traditional method would be to use
the rm command with find.

  $ find /home -name '*.swp' -exec rm -f {} +

Using find provides a powerful file finding mechanism that works with
all of the rest of the utilities.  It is a general solution.

Please also see this reference for more information:

  http://www.gnu.org/software/coreutils/faq/#Why-doesn_0027t-rm-_002dr-_002a_002epattern-recurse-like-it-should_003f

And also this one too:

  http://www.gnu.org/software/coreutils/faq/#Why-doesn_0027t-rm-_002dr-_002a_002epattern-recurse-like-it-should_003f

Bob




Information forwarded to bug-coreutils <at> gnu.org:
bug#9950; Package coreutils. (Fri, 04 Nov 2011 19:38:01 GMT) Full text and rfc822 format available.

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

From: Graham Lawrence <gl00637 <at> gmail.com>
To: 9950 <at> debbugs.gnu.org
Subject: Re: bug#9950: closed (Re: bug#9950: rm -r partial failure)
Date: Fri, 4 Nov 2011 12:35:00 -0700
I appreciate the detailed response from Bob Proulx, but I do not think
it addressed the question I raised.  I had expected "rm -rf *.swp" to
remove all the files listed by find, Mr Proulx informed me that it
would have removed none of them, but in fact what it did was remove
SOME of them.

~ $find /home -name *swp ................the original list delivered by find
/home/g/.vim/config.swp
/home/g/.vim/Notes.swp
/home/g/.vim/nzb.sh.swp
/home/g/.vim/makesess.vim.swp
/home/g/.vim/backup.sh.swp
/home/g/.vim/.vimrc.swp
/home/g/.vim/.bashrc.swp
/home/g/.vim/renamer.sh.swp
/home/g/.vim/vimcht.swp
/home/g/.vim/grepnotes.sh.swp
/home/g/Scripts/.reseq.awk.swp
/home/g/.fluxbox/.menu.swp
~ $rm -rf *.swp ...............................the doubtful rm command
~ $find /home -name *swp ..............the same find command, showing
some deleted, and some not
/home/g/.vim/Notes.swp
/home/g/.vim/backup.sh.swp
/home/g/.vim/.vimrc.swp
/home/g/Scripts/.reseq.awk.swp
/home/g/.fluxbox/.menu.swp
~ $rm -rf *swp

For example, why did it remove
/home/g/.vim/renamer.sh.swp
but ignore
/home/g/.vim/backup.sh.swp




Information forwarded to bug-coreutils <at> gnu.org:
bug#9950; Package coreutils. (Fri, 04 Nov 2011 20:30:02 GMT) Full text and rfc822 format available.

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

From: Bob Proulx <bob <at> proulx.com>
To: Graham Lawrence <gl00637 <at> gmail.com>
Cc: 9950 <at> debbugs.gnu.org
Subject: Re: bug#9950: closed (Re: bug#9950: rm -r partial failure)
Date: Fri, 4 Nov 2011 14:26:43 -0600
Graham Lawrence wrote:
> I appreciate the detailed response from Bob Proulx, but I do not think
> it addressed the question I raised.

Please keep the discussion going until we have reached consensus.

> I had expected "rm -rf *.swp" to remove all the files listed by
> find, Mr Proulx informed me that it would have removed none of them,

Not given the information discussed so far. :-)

> but in fact what it did was remove SOME of them.

What?  That is very unexpected behavior!  Please show us the result of
these commands:

  echo *.swp

  ls -ldog *.swp

What shell are you using?

  echo $0

  echo $SHELL

If that happens to turn out to be /bin/sh then please follow up by
figuring out if /bin/sh is a symlink to a different shell.  And if it
isn't a symlink try to find out what shell it is really.

  ls -ldog /bin/sh

Expansion of the '*.swp' is a function of your shell.  So finding that
information is critical to understanding the behavior.  I am using
bash.  If you are using a different shell then the behavior could be
quite different.  But it would still be a function of the shell.

What filesystem are you operating upon?  Is it a local filesystem or
a network mounted filesystem such as NFS or Samba?  'find' can print
this information.

  find . -name '*.swp' -printf '%F %p\n'

> For example, why did it remove
> /home/g/.vim/renamer.sh.swp
> but ignore
> /home/g/.vim/backup.sh.swp

I am unable to reproduce your results.  I used the following setup
actions to recreate your test case:

  mkdir g
  mkdir g/.vim
  touch g/.vim/config.swp
  touch g/.vim/Notes.swp
  touch g/.vim/nzb.sh.swp
  touch g/.vim/makesess.vim.swp
  touch g/.vim/backup.sh.swp
  touch g/.vim/.vimrc.swp
  touch g/.vim/.bashrc.swp
  touch g/.vim/renamer.sh.swp
  touch g/.vim/vimcht.swp
  touch g/.vim/grepnotes.sh.swp
  mkdir g/Scripts
  touch g/Scripts/.reseq.awk.swp
  mkdir g/.fluxbox
  touch g/.fluxbox/.menu.swp

  $ cd g

  $ find . -name '*.swp'
  ./.vim/.vimrc.swp
  ./.vim/vimcht.swp
  ./.vim/nzb.sh.swp
  ./.vim/Notes.swp
  ./.vim/config.swp
  ./.vim/makesess.vim.swp
  ./.vim/renamer.sh.swp
  ./.vim/backup.sh.swp
  ./.vim/.bashrc.swp
  ./.vim/grepnotes.sh.swp
  ./Scripts/.reseq.awk.swp
  ./.fluxbox/.menu.swp

  $ find . -name '*.swp' | wc -l
  12

  $ echo *.swp
  *.swp

  $ ls -ldog *.swp
  ls: cannot access *.swp: No such file or directory

  $ rm -rf *.swp
  $ find . -name '*.swp' | wc -l
  12

Bob




Information forwarded to bug-coreutils <at> gnu.org:
bug#9950; Package coreutils. (Fri, 04 Nov 2011 23:33:01 GMT) Full text and rfc822 format available.

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

From: Graham Lawrence <gl00637 <at> gmail.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: 9950 <at> debbugs.gnu.org
Subject: Re: bug#9950: closed (Re: bug#9950: rm -r partial failure)
Date: Fri, 4 Nov 2011 16:30:15 -0700
The system is stock slackware 13.37 on my vanilla home desktop pc, of
which I am the sole user.
Here is the data you requested.  With this new set of swp files
behavior is exactly as you said it should be.  Is there any way I can
recover the original set of swp files that I removed, or is rm for
keeps?

~ $echo *.swp
*.swp
~ $ls -ldog *.swp
ls: cannot access *.swp: No such file or directory
~ $echo $0
bash
~ $echo $SHELL
/bin/bash
~ $ls -ldog /bin/sh
lrwxrwxrwx 1 4 Oct 22 04:56 /bin/sh -> bash
~ $find . -name '*.swp' -printf '%F %p\n'
ext4 ./.vim/config.swp
ext4 ./.vim/music.sh.swp
ext4 ./.vim/freedom.swp
ext4 ./.vim/Notes.swp
ext4 ./.vim/nzb.sh.swp
ext4 ./.vim/makesess.vim.swp
ext4 ./.vim/.vimrc.swp
ext4 ./.vim/.bashrc.swp
ext4 ./.vim/renamer.sh.swp
ext4 ./.vim/vimcht.swp
ext4 ./.vim/grepnotes.sh.swp
~ $find . -name '*.swp' | wc -l
11
~ $echo *.swp
*.swp
~ $ls -ldog *.swp
ls: cannot access *.swp: No such file or directory
~ $rm -rf *.swp
~ $find . -name '*.swp' | wc -l
11
~ $find /home -name *swp
/home/g/.vim/config.swp
/home/g/.vim/music.sh.swp
/home/g/.vim/freedom.swp
/home/g/.vim/Notes.swp
/home/g/.vim/nzb.sh.swp
/home/g/.vim/makesess.vim.swp
/home/g/.vim/.vimrc.swp
/home/g/.vim/.bashrc.swp
/home/g/.vim/renamer.sh.swp
/home/g/.vim/vimcht.swp
/home/g/.vim/grepnotes.sh.swp
~ $rm -rf *.swp
~ $find /home -name *swp
/home/g/.vim/config.swp
/home/g/.vim/music.sh.swp
/home/g/.vim/freedom.swp
/home/g/.vim/Notes.swp
/home/g/.vim/nzb.sh.swp
/home/g/.vim/makesess.vim.swp
/home/g/.vim/.vimrc.swp
/home/g/.vim/.bashrc.swp
/home/g/.vim/renamer.sh.swp
/home/g/.vim/vimcht.swp
/home/g/.vim/grepnotes.sh.swp
~ $

On Fri, Nov 4, 2011 at 1:26 PM, Bob Proulx <bob <at> proulx.com> wrote:
> Graham Lawrence wrote:
>> I appreciate the detailed response from Bob Proulx, but I do not think
>> it addressed the question I raised.
>
> Please keep the discussion going until we have reached consensus.
>
>> I had expected "rm -rf *.swp" to remove all the files listed by
>> find, Mr Proulx informed me that it would have removed none of them,
>
> Not given the information discussed so far. :-)
>
>> but in fact what it did was remove SOME of them.
>
> What?  That is very unexpected behavior!  Please show us the result of
> these commands:
>
>  echo *.swp
>
>  ls -ldog *.swp
>
> What shell are you using?
>
>  echo $0
>
>  echo $SHELL
>
> If that happens to turn out to be /bin/sh then please follow up by
> figuring out if /bin/sh is a symlink to a different shell.  And if it
> isn't a symlink try to find out what shell it is really.
>
>  ls -ldog /bin/sh
>
> Expansion of the '*.swp' is a function of your shell.  So finding that
> information is critical to understanding the behavior.  I am using
> bash.  If you are using a different shell then the behavior could be
> quite different.  But it would still be a function of the shell.
>
> What filesystem are you operating upon?  Is it a local filesystem or
> a network mounted filesystem such as NFS or Samba?  'find' can print
> this information.
>
>  find . -name '*.swp' -printf '%F %p\n'
>
>> For example, why did it remove
>> /home/g/.vim/renamer.sh.swp
>> but ignore
>> /home/g/.vim/backup.sh.swp
>
> I am unable to reproduce your results.  I used the following setup
> actions to recreate your test case:
>
>  mkdir g
>  mkdir g/.vim
>  touch g/.vim/config.swp
>  touch g/.vim/Notes.swp
>  touch g/.vim/nzb.sh.swp
>  touch g/.vim/makesess.vim.swp
>  touch g/.vim/backup.sh.swp
>  touch g/.vim/.vimrc.swp
>  touch g/.vim/.bashrc.swp
>  touch g/.vim/renamer.sh.swp
>  touch g/.vim/vimcht.swp
>  touch g/.vim/grepnotes.sh.swp
>  mkdir g/Scripts
>  touch g/Scripts/.reseq.awk.swp
>  mkdir g/.fluxbox
>  touch g/.fluxbox/.menu.swp
>
>  $ cd g
>
>  $ find . -name '*.swp'
>  ./.vim/.vimrc.swp
>  ./.vim/vimcht.swp
>  ./.vim/nzb.sh.swp
>  ./.vim/Notes.swp
>  ./.vim/config.swp
>  ./.vim/makesess.vim.swp
>  ./.vim/renamer.sh.swp
>  ./.vim/backup.sh.swp
>  ./.vim/.bashrc.swp
>  ./.vim/grepnotes.sh.swp
>  ./Scripts/.reseq.awk.swp
>  ./.fluxbox/.menu.swp
>
>  $ find . -name '*.swp' | wc -l
>  12
>
>  $ echo *.swp
>  *.swp
>
>  $ ls -ldog *.swp
>  ls: cannot access *.swp: No such file or directory
>
>  $ rm -rf *.swp
>  $ find . -name '*.swp' | wc -l
>  12
>
> Bob
>




Information forwarded to bug-coreutils <at> gnu.org:
bug#9950; Package coreutils. (Sat, 05 Nov 2011 06:12:01 GMT) Full text and rfc822 format available.

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

From: Bob Proulx <bob <at> proulx.com>
To: Graham Lawrence <gl00637 <at> gmail.com>
Cc: 9950 <at> debbugs.gnu.org
Subject: Re: bug#9950: closed (Re: bug#9950: rm -r partial failure)
Date: Sat, 5 Nov 2011 00:08:39 -0600
> The system is stock slackware 13.37 on my vanilla home desktop pc, of
> which I am the sole user.

Should be okay.  I was worried that it was some cross compiled program
on a system that was not unix-like.

> Here is the data you requested.

ext4 seems reasonable.  I was worried it was some strange network
filesystem and so had unusual behavior.

> With this new set of swp files behavior is exactly as you said it
> should be.

Good! :-)

> Is there any way I can recover the original set of swp files that I
> removed, or is rm for keeps?

Not usually.  Especially on journaled filesystems the data is
reclaimed quickly.

> ~ $echo *.swp
> *.swp

No matches.

> ~ $ls -ldog *.swp
> ls: cannot access *.swp: No such file or directory

No files matched.  So if you were using 'rm *.swp' then rm wouldn't
have any files to remove either.

> ~ $echo $0
> bash

Bash should behave normally.  Was worried that it was some other
different shell that had interesting behavior.  zsh for example can
have some interesting behavior if given **/*.swp.

> ~ $ls -ldog /bin/sh
> lrwxrwxrwx 1 4 Oct 22 04:56 /bin/sh -> bash

I was only concerned about /bin/sh if $0 happened to be /bin/sh.
Since it is bash then we can stop there.

I really think that now that you know what is going on that you won't
be able to recreate any test cases where 'rm -rf *.swp' removes any
files that are not in the current directory.

Bob




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 03 Dec 2011 12:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 13 years and 199 days ago.

Previous Next


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