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

Previous Next

Full log

View this message in rfc822 format

From: Bob Proulx <bob <at> proulx.com>
To: Graham Lawrence <gl00637 <at> gmail.com>
Cc: 9950 <at> debbugs.gnu.org
Subject: 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

Previous Next

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