Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS File Recovery Programs - How do they work?

K

kainjow

Moderator emeritus
Original poster
Jun 15, 2000
7,958
7
I've been wondering, how do file recovery programs work? Once a file is deleted, the reference to it is simply deleted and the actual data is still there. So how does a program scan the hard drive to look for files? How does it know where a program starts and stops? Is there some type of low level way of doing this?? :confused:

(you can be as specific as possible.. I seriously want to know what code you could use, or the concept behind it)
 
My answer isn't going to be very helpful. However, if i had the question, I would be searching on developers.apple.com. Also, I'd be looking for reading material on there about the OS X file system, but your answer is going to be on how the fs handles files in general, and deleted files.

I'd also go and download the darwin source (os x kernel) and look at the source code for rm. That will answer a lot of your question once you understand how a file is deleted.

The next thing I would do is get on sourceforge.net and look for any open source file recovery programs for OS X. If i couldn't find any, I'd look for a PPC linux code which there is probably some port out there. After, that I'd apply my knowledge of the OS X fs and the concepts I learned from the other people's work to produce file recovery.
 
The whole concept is not too confusing.


Basically its like this [BTW for those who do know, I know I'm oversimplifying]:

Normally when you delete something, all the OS does is delete the "shortcut" to that file, it doesn't go and actually erase the file itself. It will eventually get erased when another file gets written "over" the erased file.

File recovery programs attempt to exploit the way files get "erased" be digging through the HD, but without knowing where it lies, since the "shortcut/intructions-to-the-file" have been erased. The longer you wait/use the computer, the lesser the chances are of recovering the erased file, since they may or may not have been overwritten.

Thats it basically...

If you do a "Secure empty trash", then the OS actually takes its time writing random data over that file so that it can't be recovered later. But doing this takes much longer and is unconventional for regular/day-to-day use. Its mainly intended for erasing personal data and such, not regular deletions [Movies/Music etc.]...

Hope that explains it :)
 
i think the concept is simple until you throw in the inter-workings of the file system the operating system runs.
 
I had the same kind of question. I wanted to read my entire hard drive. No one here gave me straight answers, because 1. they didn't know what they were talking about or 2. they didn't have time to answer. I went to a Unix site. I found there is a huge knowledgeable community and books for these kinds of questions when it comes to Unix/Linux and Windows. Lot of people on forums that know and are ready to help out. Lots of books availabe, in the next OS section over, but not for Mac. Good luck on your search. It's two hundred bucks an incident for technical support with Apple. Kind of makes one see why not much is developed on the Mac.

Alot of crap to put up for a developer, but still I love my Mac. Here is what I've found so far. There is a Tutorial that is called Hello Kernel.

http://developer.apple.com/document...l/KEXTConcept/KEXTConceptKEXT/hello_kext.html

Read this documentation to get yourself started. It's all there is!:( When you come to the error that is in the tutorial, let me know, I had to get past that agravating situation. I sent the error in to Apple a few weeks ago and they still haven't fixed it. Another lesson in how they treat those who are looking into to developing for them. I'm getting used to it. Next time I buy a computer I will remember it.

If you are serious about learning about this, maybe we could actually help each other out. Most people won't go deep enough to find out, because the issue (for some reason) isn't compelling enough for them to learn. But if you really want to know and I want to know, we may get more done. Let me know how the tutorial works out.
 
Jordan72 said:
I had the same kind of question. I wanted to read my entire hard drive. No one here gave me straight answers, because 1. they didn't know what they were talking about or 2. they didn't have time to answer. I went to a Unix site. I found there is a huge knowledgeable community and books for these kinds of questions when it comes to Unix/Linux and Windows. Lot of people on forums that know and are ready to help out. Lots of books availabe, in the next OS section over, but not for Mac. Good luck on your search. It's two hundred bucks an incident for technical support with Apple. Kind of makes one see why not much is developed on the Mac.

Alot of crap to put up for a developer, but still I love my Mac. Here is what I've found so far. There is a Tutorial that is called Hello Kernel.

http://developer.apple.com/document...l/KEXTConcept/KEXTConceptKEXT/hello_kext.html

Read this documentation to get yourself started. It's all there is!:( When you come to the error that is in the tutorial, let me know, I had to get past that agravating situation. I sent the error in to Apple a few weeks ago and they still haven't fixed it. Another lesson in how they treat those who are looking into to developing for them. I'm getting used to it. Next time I buy a computer I will remember it.

If you are serious about learning about this, maybe we could actually help each other out. Most people won't go deep enough to find out, because the issue (for some reason) isn't compelling enough for them to learn. But if you really want to know and I want to know, we may get more done. Let me know how the tutorial works out.
Click to expand...

Apple is weird when it comes to relationships outside of the company. Very weird.
 
hah, strange that I asked that question many years ago and now work in the business :p

bker said:
I have the same question. Any help would be appreciated.
Click to expand...

Did you read post #3? It gives a general overview of how things work.
 
The abridged version is...

All disks are formatted into blocks with a specific block size. The file system is really just a set of pointers, each pointing to the header block of a file. Typically, the first N number of blocks on the disk are the pointers to the rest of the disk. We aren't talking about the boot sector, it usually follows it. I used to know this very well, but it's been a while so...

Depending on the Filesystem, the header block might contain the pointers to all the other blocks for that file, or it might be setup as a chain (linked list), since file allocations are rarely contiguous.

Typically, once you find the first block, you can put together the file, assuming some of the blocks haven't been re-used by another file.

The disk scan utilities take so long, because they read the disk header, then go through each block to see if its allocated (known by the disk header), and if it isn't, it checks to see if it is a header block. If it's a header block, it pieces together the file and checks to see if any of the blocks were reallocated to other files.

If it can rebuild the file, it will and re-adds it to the allocation table.

In certain file systems (DOS), its a little easier, since they just wipe the first byte of the filename to indicate a deletion. They can actually recover most of the filename as well.

That's the short version. The basic premise should still be the same.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back