[Leaplist] Can a deleted file be recovered on one's personal computer?

William Ferguson ferguson.william at gmail.com
Sun Jan 3 21:33:55 EST 2010


Thanks again, Hank Lambert, Joe  Brockmeier, Jason Boxman, Jim Hartley
and John Simpson.

I have a much better appreciation now of how critically important
using "Move to Trash" or "rm" can be if
preserving a file is one's intention.

Since I have a lot of respect for the Fedora use of the Gnome Nautilus
File Manager program, I'm
surprised that "Move to Trash" is not explicit in its effect. It's
further disturbing that sometimes,
using "Move to Trash" does exactly that!

As soon as Jim and John discussed the scattering of inodes all over
the Hard Drive I decided
to put my concerns to rest and accept the fact that  life at the
Computer is not always smooth sailing.

My memory is poor nowadays. So, during last night's sleep period it
occurred to me that only 5 days anterior to
my original post on this subject, I had completely backed up my
/home/william directory in which
the "lost" files had been stored.

All the files were recovered this morning thanks to a Simple Tech
External Hard Drive.

Happy New Year!

William





On Sun, Jan 3, 2010 at 3:32 PM, John Simpson <jms1 at jms1.net> wrote:
> On 2010-01-02, at 0953, William Ferguson wrote:
>>
>> I have always had (up to this point in time) the understanding that tho' I delete a file, in whichever way I did it, that somewhere and somehow, on the hard drive, the file actually still exists.
>>
>> Right off the bat handle----Is that understanding faulty?
>
> it actually depends on your terminology.
>
> most peoples' understanding of the word "file" is that it's a single object. you can copy files, move files, edit files, delete files, and so forth.
>
> however, a "file" is really a logical abstraction for "a sequence of bytes". it's the same concept as saying that a "word" is a logical abstraction for "a sequence of letters".
>
> when a file is created, the operating system allocates blocks of disk space to hold the sequence of bytes within the file. it also creates an "inode", which contains (among other things) a list of which block numbers are holding the data, and a "directory entry", which contains a name and the inode number. (there are minor differences in the contents of an inode, for very small and very large files, but for 99% of files, what i've explained is exactly what happens.)
>
> when you delete a file, the directory entry is removed. if that directory entry was the only name pointing to that inode, then the inode is marked as "empty".
>
> however, until or unless those disk blocks are allocated for some other file, they do still contain the original bytes from the file.
>
>
>> And, if the file, tho' deleted, is still in existence somewhere on the disk, can it be retrieved/recovered?
>
>
> hrmmmm... if you know the old inode number, and the inode hasn't been re-used, and the block numbers stored within the inode haven't been overwritten, then it *is* possible to read that inode and extract the original disk block numbers. assuming those disk blocks haven't been re-used, it's also possible to read those blocks from the disk and re-construct the original file.
>
> however, most linux users these days are using ext3 filesystems. when ext3 deletes an inode, it overwites all of the block numbers in the inode with zeros.
>
> which means that the contents of the file *are* still out there (because the blocks holding that data have not been re-used yet) but unless you have some other way to know what the original block numbers were, there's no way to recover them.
>
>
>> Do specialists and Companies who offer a service in which they offer to recover lost data files----do they offer to recover files which have been deleted with the "rm" command?
>>
>> Or do such specialists or Companies work almost exclusively with Windows Op. Systems?
>
> they are mostly windows-oriented, because most of the clients who would need that kind of service are running windows. however, some companies (and individuals) offer this kind of service for linux machines as well. i know this because i am one- i had a client several years ago who paid me to un-delete a file from a linux system. luckily it was an ext2 filesystem, and i was able to shut the machine down while working on it.
>
> there are programs out there which can un-delete files from ext2 and (usually) ext3 filesystems, provided the original disk blocks involved haven't been changed. this web page was written by somebody who wrote such a program.
>
> http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html
>
>
>> I've read here on Leaplist that there are programs which will "wipe" over files which the User wishes to expunge. It's my understanding that the User may choose a large number of times to wipe over the file to get rid of the file permanently.
>>
>> So, if it is agreed by experienced Linux users that to really get rid of a file in the permanent un-retrievable sense it has to be "wiped" over 25 or more times doesn't that suggest that somehow it's very hard to remove a file even with the "rm" or "delete" commands?
>
> again, it depends on whether you think of a "file" as an atomic object, or if you think of it in terms of the sequence of bytes it contains. and it also depends on what your idea of "existence" is. (wow, i didn't realize i was such a philosopher.)
>
> again, most people think of a "file" as this atomic object, which can be manipulated using the functions supplied by the operating system (such as open(), read(), write(), and so forth.) and when you use "rm" on a "file", and there are no other directory names pointing to the same inode (i.e. no "hard links") then the rm command does indeed "remove" the file, in the sense that the open() function can no longer give you access to the sequence of bytes contained within that file. if you think in "normal" terms, then yes, the file is gone.
>
> however, if you're willing to think of the disk as a sequence of blocks of bytes, then technically the "file" still "exists", in the sense that the original bytes which made up the file are physically still stored on the disk, at least until those blocks are re-used to hold the data for some other file.
>
>
>> And, to me, the existence of a "Wipe" command (I've forgotten what it's actually called) tells me that even tho' deleted or removed, the data is still on the hard drive somewhere.
>
> exactly.
>
> these "wipe" programs work by reading the inode to find the right block numbers, and then accessing the disk directly (bypassing the OS) with instructions like "write this block of zeros to disk block number 12345"... basically the same instructions that the operating system would send to the disk, after de-referencing the abstraction layers provided by the filesystem itself. by overwriting the raw disk blocks with zeros (or ones, or fixed or random patterns of ones and zeros) it makes it impossible for the controller on the bottom of the hard disk itself to recover the original contents of those blocks.
>
> the high-priced data recovery companies work by physically removing the disk platters from the hard disk enclosure and using a different set of disk heads, which are much more sensitive than the heads normally used in hard drives, and are sometimes able to pick up very weak remnants of the former contents of a disk block.
>
> overwriting a disk block multiple times is a way to prevent even this kind of attack from working. there is a DoD standard which requires 3 overwrites in order to full erase a disk containing classified information, however some people go much further. apple's "secure erase" procedure uses either 7 or 35(!) passes to make sure there is no way that even a commercial data recovery system can find the original data.
>
> http://support.apple.com/kb/TA24002
>
> my apologies for the "information overload", i'm sure it's probably more than you ever wanted to know about deleting files- but i can see others being curious as well, so i may as well try to answer the questions as fully as possible. (bryan smith isn't the only one who likes to write books for mailing lists...)
>
> take care.
>
> ----------------------------------------------------------------
> | John M. Simpson    ---   KG4ZOW   ---    Programmer At Large |
> | http://www.jms1.net/                         <jms1 at jms1.net> |
> ----------------------------------------------------------------
> | http://video.google.com/videoplay?docid=-1656880303867390173 |
> ----------------------------------------------------------------
>
>
>
>
>
>
> _______________________________________________
> Leaplist mailing list
> Leaplist at leap-cf.org
> http://lists.leap-cf.org/mailman/listinfo/leaplist
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



More information about the Leaplist mailing list