[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9950: closed (Re: bug#9950: rm -r partial failure)
From: |
Bob Proulx |
Subject: |
bug#9950: closed (Re: bug#9950: rm -r partial failure) |
Date: |
Sat, 5 Nov 2011 00:08:39 -0600 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
> 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