remind me ... (file undelete on FreeBSD 5.4)

[Bill Vermillion]

They all laughed on Sat, Nov 26, 2005 at 02:35  when user said:
 

> ln -s /some/dir/somewhere local

> (used the symlink named local for a while)

> rm -rf local

> local still exists in my current working directory, but now
> /some/dir/somewhere is gone.

> ---

> So I rm -rf'd a symlink. I just wanted to delete the link, and
> of course, it deleted the target.

To remove a symlink a simple 'rm' is all that is needed.  There was
a bug in the past with 'bash' that did nasty and unexpected things
like removing all files in the directorys pointed to by synlinks
but leaving the symlink alone.  I don't know how/when this was
fixed as I've never used bash, and stick with David Korn's genuine
'ksh' and not the clones of it.

> I then immediately mounted the filesystem read-only. (it's all I could
> think of to do to preserve things right at that state...)

Good.  At least nothing now will be changed.

> I did not have a snapshot enabled on the filesystem.

> I know the bits are still there ... is there any way to get them
> back ?

With a fair amount of work there is.

The only one I've used is TCT - The Coroners Toolkit - written
by Wietse Venema and Dan Farmer.

You can get it from either of their websites:

http://www.fish.com/forensics
or
http://www.porcupine.org/forensics

The two main pieces of the program are 'unrm' - which could be
described as a specialized 'dd' - as it dumps only unallocated
inodes to a file.  It says it supports UFS2 and references
FreeBSD 5.x - but the last update was in 2004.

The second is 'lazarus' which goes through all the data and then
puts the pieces into files so you can see what is found and what
you want to do with it.

It will give you LOTS AND LOTS of things you don't want.  The first
time I tested it [years ago] I found files I had removed over a
year ago.   There is an html option to be able to browse all the
found pieces parts which lazarus has raised from the dead and 
it breaks things down into colors to make them easily identifiable.

It WILL be a lot of work.

I also accidentally rm'ed some files in my home directory, and had
no idea of when I had done it, so I ran 'unrm' dumped the files to
another division [I had to do it in pieces because of space]
ran lazarus, and then moved those pieces/parts over to my XP
machine [with a decent vi and ksh on it].

It can be a long tedious job - but I don't know of any other tool.

BTW - the bash problem as I recall came from using tab expansion.
What shell were you using?

And  the  -rf  option to rm will never warn you of anything.

I last really nuked an important filesystem on an SGI in about
1996.  I had done it once or twice before since I started using 
Unix systems in 1983.

I've learned that for some places I'll perform an 'ls' with the
same options/wildcards as I would use to rm, and then if that looks
right, I used the line editing faciltiy of ksh [I like vi] to
re-execute the command substituting 'rm' for the 'ls'.

I've since reverted to using partial wildcards, double checking
command lines to make sure there is no space around a '*', etc.

It takes a bit more time, but sometimes it takes a big disaster
to make you stay on your toes.

And interesting anecdote on the SGI incident.

I had tape backups.  So I reinstalled the base OS with the
convulted way that SGI had depending on which BIOS you had on the
particular machine.

After configuring the NIC cards I started the backup restore - from
a tape drive on the network - as the SGI didn't have anything built
in - including no floppies.

Restore worked for a while and then stopped dead.  So I go through
this a second time - same thing.

The first person who had installed that system has the SGI as his
first introcution to Unix coming from a DOS and CP/M world.

The default NIC used the DC-15 connector with a convertor to
be able to handle 10baseT or 10base2 or 10base5.  Since he did not
have a convertor he made the secondary NIC with the 10baseT
connector the one on the machine.

The install set things up with the convertor as being the default -
as this had been added later on.

So part way through the install the config file for the default NIC
was changed so now the system was looking for the tape on the other
NIC.

So after I figured that out, and configured the machine to match
the backup, I started the tape restore, locked up, it was about
1AM.  Got up at 6AM and drove the the site.  And found the tape
drive had failed about 3AM.

Total failure on the drive.  I forgot how I got things back but it
did involve using another tape drive on another OS, pullingh all
that data off there, and then manually xfering over the 'net a bit
at a time.

That was so long and so involved I've been super-extra-careful -
always using the belt and suspendors approach since then.

Sorry you had the problem, but TCT is the only package that I've
seen that will do this for you.

Wietse and Dan are very well known and respected, and Wietse wrote
the original tcpwrappers back in 1995.

Good luck.

Bill
-- 
Bill Vermillion - bv @ wjv . com