Undelete utilities

[CornedBee]

You don't need a fileserver for CVS/SVN/whatever. You can run it locally. Or you can use the direct filesystem access that both provide. It's all pretty easy, and absolutely wonderful. Nowadays, whenever I start a project, the first thing I do is creating an SVN repository for it.

Though you might want to try git as an alternative.

[laserlight]

Though you might want to try git as an alternative.

Be warned that there is less Windows support for git compared to CVS or Subversion (or Bazaar, for that matter).

[dwks]

How new is your hard drive? How full is it? When did you last defragment it?

If you have an older drive or it's very nearly full or very fragmented, a problem could have occured with your hardware, instead of with Code::Blocks. Files become crosslinked etc quite easily when they're in 3,000 fragments . . . that happened to me recently to an entire folder, though fortunately I had a very recent backup of the files in question. I've deleted 8% of the files on the hard drive and had no further problems. I should probably defragment it sooner or later too.

Have you done anything unusual recently to your hard drive? With an old version of a live Linux CD, any file I accessed on the partition tended to get crosslinked or truncated. And any folder I created would be perfectly visible in the Linux, even across reboots, but completely invisible in Linux.

Or, of course, it could just have been Code::Blocks messing up.

The longer you leave it, the less likely you'll be able to recover the file. If you tried an undelete utility immediately after you discovered that it was gone, you might have had a chance at recovering it; but by now, if you've done other work etc then it's almost certainly gone.

[brewbuck]

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?

I'd go download a Knoppix image and boot off the CD. Then grep the hard drive for some key string which you know occurs in your file. With any luck, the position on disk where the file resides will pop up, and you can copy the raw bits off to some safe location. Unless the file itself has been trashed -- but the fact that it's 0 bytes seems to indicate that the directory entry has been replaced. It's quite possible that your file is intact on the drive somewhere.

[@nthony]

Is there any way I can "lock" the sector/blocks where the directory/file is located from further use?
Also, I've used grep with files before, but how would I "grep" my harddrive in terms of raw bytes? Also are there any concerns I should worry about when mounting my NTFS drive with Knoppix?

[brewbuck]

Is there any way I can "lock" the sector/blocks where the directory/file is located from further use?

Not without some special utility. Basically, you'd allocate those blocks to a "dummy" file to prevent them from being used by something else. Similar to actually undeleting it, actually.

Also, I've used grep with files before, but how would I "grep" my harddrive in terms of raw bytes? Also are there any concerns I should worry about when mounting my NTFS drive with Knoppix?

You don't have to mount it at all. Just grep the raw partition. Your drive will be designated by a file either /dev/hdX or /dev/sdX, where X is a partition number. For instance, if your drive is IDE and it's the primary drive, the partitions will be labeled /dev/hda1, /dev/hda2, etc. So...

$ grep -b "something distinctive" /dev/hda1

This will search the first partition of the primary IDE disk for occurrences of "something distinctive," and print out the byte position of the match, if found. Then, you can use the "dd" utility to extract the raw data.

Try the grep first -- if it works, I'll explain the exact usage of dd.

EDIT: In the meantime, don't do ANYTHING on your box. The most recently deleted files are the best candidates to be overwritten by new activity.

[@nthony]

I happen to have a Ubuntu disk on hand, can I use the grep utility from this as well?

[brewbuck]

I happen to have a Ubuntu disk on hand, can I use the grep utility from this as well?

Sure... You should be able to boot off that to the installer. When it comes up, don't do anything. Just hit Alt-F2. You should be at a root prompt.

[@nthony]

Window's encoding (1252 I think my file was) won't intefere much with grep will it (its still ASCII right?)

[brewbuck]

Window's encoding (1252 I think my file was) won't intefere much with grep will it (its still ASCII right?)

The lower 7 bits of all Latin Windows encodings are identical to ASCII. So yeah, it'll work fine.

[@nthony]

Ok, so I'm here via Ubuntu's live CD, still amazed at how much can actually be accomplished with just 1 gig of memory and a 700 mb CD, but mostly because I'm afraid to boot into windows and risk changing the state of the FS (though in all honesty, I've been using it 2 days now since the incident occured).
After grepping the primary partition for about 3.5 hours now (I guess that's normal for 120 GB), I've gotten mixed results:
Of the 4 or 5 patterns searched for that I remembered best from the lost file, 2 came back as matches. However, grep did not report info on where the matches came from (I've tried -A,B,C,H), the only thing that it returned was "Binary file /dev/sda2 matches" (no offset information either). Maybe this is because those options do not apply to binary files or maybe the grep utility on the live CD differs, I'm not entirely sure. I am pretty sure though that the search terms were exclusive to that file, but I cannot be certain without seeing the surrounding bytes.
So now my question would be, how can I find out where grep is finding the matches and what are the surrounding byte values?
And also, is it possible that my file has been partially destroyed, explaining why grep found some terms, but not all?
And of course, the most important, if this actually does turn out to be parts of my lost file, how can I reclaim them? I mean, it can't be just as easy as copying a series of blocks right (i.e. what happens if the file was not contiguous)?
Trying not to get my hopes up too high though, I don't think I could bear getting shot down again...

[matsp]

"grep -b" should give you a "byte-offset", according to this:
http://linux.die.net/man/1/grep

You can do "man grep" in your ubuntu to see if it's there - it may be that you have a reduced set of grep functionality if the bootable CD uses something like "busybox" as the shell (busybox is a small shell with LOTS of stuff built in as opposed to external tools).

--
Mats

[@nthony]

Yep, I was using brewbuck's instructions from the previous post, in addition to the other switches I mentioned (and prefixed with "sudo", to be completely verbose). Man gave a grep page with full listings, but I guess only some switches are actually implemented on the live CD then? (though $SHELL is /bin/bash)

[matsp]

Try using "find / -name grep -print" to see if there's a "real" grep somewhere in your filesystem (could try "ls -l /bin/grep" or some such first). Watch out for symbolic links - you could have grep linked to busybox for example, in which case busybox will look at argv[0] to decide what to do.

--
Mats

[CornedBee]

Eh, find takes forever. Use
which grep
to find out the exact path of the grep binary found by the PATH mechanism.