Undelete utilities

[@nthony]

To what extent will they work?
My IDE (CodeBlocks) has just eaten my 4000+ line C file, reducing it to absolutely nothing (officially 0 bytes). From what I've heard on the subject, deleting a file from the FS is manageable for undelete utilities, however if you write all zeroes to the file, the chance of retreiving it is slim to none. Since this is essentially what happened in my case, I'm thinking my prospects are very slim here. I've already tried ntfsundelete.com, which seemed proficient at finding and undeleting every other file, including files I had deleted years ago, except the file in question.
So is it worth it to spend the money on another utility, or do they essentially all yield the same results? What is the prognosis for my situation here?

[indigo0086]

Trashign it and rewriting it are two different things. Under what circumstances did CodeBlock murder this file? I'd report it fast if it was a recent revision. I don't know how to help, but would like to hear the diagnosis from the team on the issue.

[matsp]

It very much depends on how the tool works: Many times, the new file is created as a temporary file, then the old file renamed to make a backup, and finally the temporary file is renamed to the original name. So edit foo.c -> save to temp.aaa -> rename foo.c to foo.bak -> rename temp.aaa to foo.c.

But if the editor renames the original file first and then writes the new file as "foo.c" and it's got some rubbish instead of your file-content, then that's pretty much it.

Undelete can only fix when a file is deleted, not when the existing content is replaced by something else in the existing place.

--
Mats

[laserlight]

however if you write all zeroes to the file, the chance of retreiving it is slim to none

Unless you have some of those nifty tools used in computer forensics, or if it has been repeatedly rewritten with garbage and then zeroed, or so I have heard. Unfortunately, I have no idea how to get them or how exactly do they work, though my guess is that they are just sensitive enough to read traces of the overwritten data and guess the previous data from those traces.

It will not help you now, but perhaps you should have used version control and taken backups?

[@nthony]

I was wondering about that too, because I know of the free ones that quasi-work and the one's you pay for (perhaps better?) and then I know there are the ones that only FBI crime labs get, which I would love to have right about now.

The guys over at the codeblocks forums say that the file writing process works as indigo suggested, but after I posed some doubts, there may have been some old code that instead directly overwrote the file. You can follow this topic here. I was using a Nightly build, released a couple of months ago. As they suggested, I tried looking for the temp file used as a backup between file writing (.cbTemp or .backup) but neither were found either in tact or via the undelete utility.

I save often, and since I don't expect my IDE to eat my file (crash maybe, but not empty the file completely) I tend not to keep so many "backups". I had a standing backup from the early versions of my program as I was adding new features in case they did not work and I needed to revert back, so unfortunately the only backup I have is so old it is virtually unusable...

[laserlight]

I save often, and since I don't expect my IDE to eat my file (crash maybe, but not empty the file completely) I tend not to keep so many "backups". I had a standing backup from the early versions of my program as I was adding new features in case they did not work and I needed to revert back, so unfortunately the only backup I have is so old it is virtually unusable...

Even if your IDE does not "eat" your file, you might accidentally do it yourself In fact, a version control system is especially handy when you are adding new features as it makes reverting to older (and working) versions easier, and you could save/commit/record versions often and save space by not having a standalone backup copy each time you want to save the current version.

[matsp]

Even if your IDE does not "eat" your file, you might accidentally do it yourself In fact, a version control system is especially handy when you are adding new features as it makes reverting to older (and working) versions easier, and you could save/commit/record versions often and save space by not having a standalone backup copy each time you want to save the current version.

Not to mention that you could revert only PARTS of a change (ok, so you probably need revert all, then get the change out as a diff and then apply parts back in as a patch or such).

--
Mats

[brewbuck]

Not to mention that you could revert only PARTS of a change (ok, so you probably need revert all, then get the change out as a diff and then apply parts back in as a patch or such).

rcs, although considered "primitive" by most people, makes it easy to revert only certain parts of a change.

cvs was originally built on top of rcs, by the way.

[@nthony]

From my brief encounters with cvs in the past, I came away thinking you needed a file server for this or ftp of some sort, is this correct? I guess its worth learning how to set it up correctly, though, at the moment, I haven't much reason to...

Edit: I have another question:
If I can obtain a copy of the executable from a recent version of my application, is it worth attempting to reverse engineer it? Exactly how accurate to the original can I expect the resulting code to be?

[brewbuck]

From my brief encounters with cvs in the past, I came away thinking you needed a file server for this or ftp of some sort, is this correct? I guess its worth learning how to set it up correctly, though, at the moment, I haven't much reason to...

If you can ssh to a machine, you can run CVS from it.

[robwhit]

If I can obtain a copy of the executable from a recent version of my application, is it worth attempting to reverse engineer it? Exactly how accurate to the original can I expect the resulting code to be?

what optimizations did you compile it with? did you use the debug setting? if you did, the code should be mostly there in the exe.

[VirtualAce]

You won't be able to get back to C from your EXE.

If your file has been trashed you won't be able to recover it if you have done any other operations on your drive.

Essentially the data that was your file may still be on the disk per se, but the filesystem says your file is now 0 bytes. The way to get past this is to remove the end of file descriptor but you will need to learn up on NTFS to do this. But since your file is now zero bytes all of the other data past the end of file descriptor can be overwritten by other processes since it has been declared as 'available'.

I give you a 10% chance of getting your file back. Undelete only fixes files that were deleted at one time - not files that had their data scrambled or removed.

And why do you have 4000 lines of code in one file?

[@nthony]

That was all of my front end code (GUI and User configuration), I have another 4000+ line file with all of my back-end code, which luckily is still intact, but is rendered useless without the front-end to drive it. Unfortunately I did compile with full optimizations on and no debug code, so I guess reversing the .exe will be of little use then?

Indeed, I was thinking about what would happen if I simply "read" past what windows said was the end of the file, but I would not know how to do this. Also if some files have been created since then, would that essentially garauntee that the space free'd up by the emptying of my file is no probably taken again? Are there any utilities that can alter NTFS file descriptors as you say?

[Salem]

diskprobe
This will allow you to scan the disk sector by sector for your file fragments. There's even a search mode if you can remember fragments of your code. With any luck, most of the lost file will be in one or two consecutive runs of sectors on disk. Once found, you can copy the sectors to a real file on another disk (don't write to the one you're diagnosing).

You should be able to find the program buried somewhere on your XP installation CD.

You should be aware that the more you've used this disk since the files were lost, the less your chance of recovery.

As for version control, I've used http://tortoisesvn.tigris.org/ recently. It integrates nicely into windows explorer (lots of nice right-click context menu functionality).

[VirtualAce]

The reason for the low chances of recovery are that the disk is always being accessed while inside of Windows. Most of the swap file is probably in the same place on the disk every time - hence why Windows tends to destroy hard drives where the swap file is. But Salem is right in that the more you use your computer the more other programs can use those sectors that contain your file data.

You will need to do a recovery immediately. Back in the DOS days this wasn't such an issue because only 1 task was running (save for TSRs) and the disk was not accessed nearly as much. Inside of Windows there are a plethora of tasks and modules running all asking for access to the drive at one point or another. If Windows has granted any of these processes access to the sectors that were your file, you will lose the data.