bug#9950: closed (Re: bug#9950: rm -r partial failure)

[Bob Proulx]

> 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