Undelete

Undelete

Post by Nikita V. Youshchenk » Wed, 11 Dec 1996 04:00:00



Hi all.
  Have you ever typed 'rm filename' and only later understood what you
have done ?
  If yes, you will agree that undelete is really neseccary.

  Ok, I can use Midnight Commander's undelete to recover files that are
smaller than 12k - it works great. But if file is larger ?..

  Does anyone know what to do ?

  ( Note: yesterday I had to use dd if=/dev/hda4 ... to copy something
to dos partition and then find data there ...  It took a few hours, and
I didn't like it at all ... )

 
 
 

Undelete

Post by Michael Taba » Wed, 11 Dec 1996 04:00:00


Try putting something like this in your .cshrc or .bashrc:

alias rm       'mv \!* ~/.trashcan'       # junk file(s) to trashcan
alias mtcan     'rm -f ~/.trashcan/*'      # irretrievably empty trash

It's not an undelete, but it does offer some safety from deleting
something important.


> Hi all.
>   Have you ever typed 'rm filename' and only later understood what you
> have done ?
>   If yes, you will agree that undelete is really neseccary.

>   Ok, I can use Midnight Commander's undelete to recover files that are
> smaller than 12k - it works great. But if file is larger ?..

>   Does anyone know what to do ?

>   ( Note: yesterday I had to use dd if=/dev/hda4 ... to copy something
> to dos partition and then find data there ...  It took a few hours, and
> I didn't like it at all ... )

--


|    /   \         .-.
|   /     \       /   \       .-.     .-.     _   _
+--/-------\-----/-----\-----/---\---/---\---/-\-/-\/\/---
| /         \   /       \   /     '-'     '-'
|/           '-'         '-'
See the "PDK Home Page" at http://www.msp.sc.ti.com/~http/pdk/pdk.html

 
 
 

Undelete

Post by Lee All » Wed, 11 Dec 1996 04:00:00


Quote:>alias rm       'mv \!* ~/.trashcan'       # junk file(s) to trashcan
>alias mtcan     'rm -f ~/.trashcan/*'      # irretrievably empty trash

Very slick!
 
 
 

Undelete

Post by Nikita V. Youshchenk » Thu, 12 Dec 1996 04:00:00



> Try putting something like this in your .cshrc or .bashrc:

> alias rm       'mv \!* ~/.trashcan'       # junk file(s) to trashcan
> alias mtcan     'rm -f ~/.trashcan/*'      # irretrievably empty trash

> It's not an undelete, but it does offer some safety from deleting
> something important.

It is good, but I'd like to know, is REALLY undelete utility available
Is it at least possible to write it ?
 
 
 

Undelete

Post by Geoff Sho » Fri, 13 Dec 1996 04:00:00



:   Have you ever typed 'rm filename' and only later understood what you
: have done ?

One way to avoid deleting essential system files is to make a hard link
from the file to somewhere else, eg:

ln /vmlinuz /backups/vmlinuz

Even if you delete /vmlinuz, /backup/vmlinuz will still be there.  And
because it's just a link, it doesn't take up any extra disk space.

For other files, you would need to redefine `rm' to do something else,
like move the file to a backup directory.  You could run a nightly
job to compress them and delete the really old/large ones.

        Geoff
--
----------------------------------------------------------------------------
Ever sit and watch ants? They're always busy with                Geoff Short

can't identify with that kind of work ethic. http://kipper.york.ac.uk/~geoff

 
 
 

Undelete

Post by David E. F » Sat, 14 Dec 1996 04:00:00



>It is good, but I'd like to know, is REALLY undelete utility available
>Is it at least possible to write it ?

Well, Midnight Commander has an undelete feature, so I wouldn't say
undelete is impossible to write. Undeletion, of course, is a tricky
operation on Unix though, for two reasons:

* The structure of the filesystem.
* the likelihood that other processes / users are using the disk
  too.

In your earlier post you mentioned files larger than 12K not being
able to be undeleted with mc. Well, this is due to the underlying
structure of the Linux filesystem (assuming of course ext2.) There
is room in the inode for 12 block numbers; these are called direct
blocks. There are also three (?) pointers to indirect blocks (or
two pointers to indirect blocks + 1 pointer to a "double indirect"
block (I'm not sure which is accurate.)

If your file is larger than 12K, one of the pointers in the inode
will point to another disk block that contains block numbers (single
indirect). This not only makes the retrieval process a bit trickier,
but it's possible that this block may get reused by something else,
and now there's no way to get to the rest of the file.

Additionally, of course (but depending on usage) since once a
file is deleted its blocks get returned to the free list, someone
else (a uesr or process - even something that's sitting there like
syslog) scribbles over any of the blocks that your file used to
occupy. Again, bye-bye file.

--
------------------------------------------------------------------------
David E. Fox                 Tax              Thanks for lettimg me


-----------------------------------------------------------------------

 
 
 

Undelete

Post by nicholas llo » Sat, 21 Dec 1996 04:00:00


:
: One way to avoid deleting essential system files is to make a hard link
: from the file to somewhere else, eg:
:
: ln /vmlinuz /backups/vmlinuz
:
: Even if you delete /vmlinuz, /backup/vmlinuz will still be there.  And
: because it's just a link, it doesn't take up any extra disk space.

I thought that since hard links were indistingushable from the actual file,
removing a hard link removes the file as sure as removing the original name.
I thought that's what soft links were for: to link to something but not worry
about removing it since a soft link removal only removes the link itself,
not what it points to. I could be wrong - someone please educate me.

 
 
 

Undelete

Post by Chris MacLell » Sat, 21 Dec 1996 04:00:00


|> I thought that since hard links were indistingushable from the actual file,
|> removing a hard link removes the file as sure as removing the original name.
|> I thought that's what soft links were for: to link to something but not worry
|> about removing it since a soft link removal only removes the link itself,
|> not what it points to. I could be wrong - someone please educate me.

First, hard links to directories are not allowed.

Second, a hard link is equivalent to a local copy of the
file linked to, where a symbolic link 'points' to the
original.  Both hard and symbolic (soft) links can
be (actually, are) deleted without deleting the original.

 
 
 

Undelete

Post by nicholas llo » Tue, 24 Dec 1996 04:00:00


:|> I thought that since hard links were indistingushable from the actual file,
:|> removing a hard link removes the file as sure as removing the original name.
:|> I thought that's what soft links were for: to link to something but not worry
:|> about removing it since a soft link removal only removes the link itself,
:|> not what it points to. I could be wrong - someone please educate me.
:
: First, hard links to directories are not allowed.
:
: Second, a hard link is equivalent to a local copy of the
: file linked to, where a symbolic link 'points' to the
: original.  Both hard and symbolic (soft) links can
: be (actually, are) deleted without deleting the original.

Yes I see where I was wrong. Instead of posting, I should have
just done what I did this morning: create a test case and see
what happens when I remove a hard link. Ah well, no one's perfect.

 
 
 

Undelete

Post by Nikita V. Youshchenk » Wed, 25 Dec 1996 04:00:00


C>

Quote:> First, hard links to directories are not allowed.

> Second, a hard link is equivalent to a local copy of the
> file linked

  No it isn't. Hard link is "another name" of the same file, it doesn't
use any aditional disk space.
 
 
 

Undelete

Post by Nand Bharadw » Thu, 26 Dec 1996 04:00:00



: :
: : One way to avoid deleting essential system files is to make a hard link
: : from the file to somewhere else, eg:
: :
: : ln /vmlinuz /backups/vmlinuz
: :
: : Even if you delete /vmlinuz, /backup/vmlinuz will still be there.  And
: : because it's just a link, it doesn't take up any extra disk space.

: I thought that since hard links were indistingushable from the actual file,
: removing a hard link removes the file as sure as removing the original name.
: I thought that's what soft links were for: to link to something but not worry
: about removing it since a soft link removal only removes the link itself,
: not what it points to. I could be wrong - someone please educate me.

Another way of ensuring that you don't clobber essential files is to
use the chattr command. Do a man chattr to learn more about this. Also
see lsattr. As an example, if you want to protect file foobar from
deletion, modification, etc. do the following:
              chattr +i foobar
Now, no one, not even root can touch this file!!. If you later decide that
foobar needs to be nuked do:
              chattr -i foobar
              rm foobar
Hope this helps.

Regards nand

 
 
 

Undelete

Post by Lee Sau Dan ~ » Fri, 27 Dec 1996 04:00:00


    nicholas> I thought that since hard links were indistingushable
    nicholas> from the actual file, removing a hard link removes the
    nicholas> file as sure as removing the original name.  I thought
    nicholas> that's what soft links were for: to link to something
    nicholas> but not worry about removing it since a soft link
    nicholas> removal only removes the link itself, not what it points
    nicholas> to. I could be wrong - someone please educate me.

Removing a hardlink removes  a file IF AND  ONLY  IF that is  the LAST
hardlink to that file.  You can find out the number of links to a file
(this   number  is a.k.a.    the  reference count)   by using  "ls  -l
<filename>".  The number   after  the "-rwx------" column   gives  the
reference count.

Perform your own experiments with "ln" and  "rm" on some useless files
(hint: creat such files with "touch")  to find out how their reference
counts change, and try to guess  how the OS  knows when an "rm" (which
indeed uses  the system  call unlink() )   removes a file and  when it
removes solely the hard-link.  Suggest why  this system call gets such
a name.

--

.----------------------------------------------------------------------------.

`----------------------------------------------------------------------------'

 
 
 

Undelete

Post by William Burr » Mon, 30 Dec 1996 04:00:00


: Now, no one, not even root can touch this file!!. If you later decide that
: foobar needs to be nuked do:
:               chattr -i foobar
:               rm foobar
: Hope this helps.

However, as people following the thread and experimenting for themselves
may be learning, this is not guaranteed to nuke the file.  Short of
truncating the file before unlink()ing (using rm or whatever), that file
could still exist somewhere in the filesystem.  

(Here, one might even sit down and consider the the philosophy of what a
file is.  IMHO, it is the data blocks or contents of the file, not the
filesystem related gumph.)

--
William Burrow  --  Fredericton Area Network, New Brunswick, Canada
Copyright 1996 William Burrow  
Canada's federal regulator says it may regulate content on the Internet to
provide for more Canadian content.   (Ottawa Citizen 15 Nov 96 D15)

 
 
 

1. undelete on ext2fs | recover vs. undelete vs. debugfs

Hi all,
48 hours ago I didn't know a thing about undeleting on extfs at all.

As u can imagine: something really bad happened, unfortunately while doing the
backup job.
The hdd/filesystem my /home was on seemed to be very unstable, so I decided to
make a backup,
format etc... and copy the backup back to /home.

Unfortunately the box crashed while backing up - resulting in a non existing
backup and an *empty* partition.
(I think the fs was corrupted and e2fsck did its job...)
I unmounted as soon as possible and a lot of data still seems to be there.

OK, some facts:
I used lsdel within debugfs of the ext2utils to find out that there is lots of
stuff that might be recoverable.
My Prob: I lost about 10GB of data within approx. 27.000 files.
Doing this job manually would take ages.

I read a lot of webpages and post in groups like this find out that there's
three tools worth giving them a try:
undelete from http://recover.sourceforge.net/linux/
recover from http://www1.lunetix.de/download/
midnight commander
(all using e2fsprogs)

Recover is perfect for finding and recovering files by their characteristics.
You can filter out a single file or hundreds, no matter.
Problem: it doesn't recover the original name of the file and testing dozends
of file extensions with ~30.000 files might take time...

Midnight commander shows a list of all inodes and recovers selected files.
Problem: same as using recover

Undelete is different but good as well. It shows all recoverable files, their
names and characteristics in a list. The user might now choose ONE file to
restore from the list. It's restored with its proper name and all.
Problem: restore one file, and the next one, and the next one.... you see -
takes ages again.

Question: Is there a tool for automated file recovery that:
1) Lets me specify files to recover by characteristics (size, uid...)
2) Recovers the filename or at least the extension properly ?

Another question is:
Is there any way to recover the directory structure?

Last and least question to people who know a bit about ext2:
What would happen if I just unset all deleted flags, set the count to 1 etc.?
I'm quite sure that no inode was reused since what ever happened.

ThX for your time.
Maybe someone knows the answer - I would be glad to get helpful replies.
Ben

P.S. Sorry for my non-perfect english ;-)

2. Mutex use in device drivers

3. Undelete

4. trouble moving a file ystem

5. is there undelete for Linux?

6. Gateway unter SunOS 4.1 -HELP

7. looking for undelete

8. Free OS Install Fest April 9 6:10 pm at Washington Square New York

9. Undelete for FAT/VFAT?

10. Undelete files on Unix

11. Undelete info for Unix

12. simple undelete

13. Undelete command