Undelete utilities

This is a discussion on Undelete utilities within the Tech Board forums, part of the Community Boards category; You don't need a fileserver for CVS/SVN/whatever. You can run it locally. Or you can use the direct filesystem access ...

  1. #16
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  2. #17
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,401
    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).
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #18
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    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.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  4. #19
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by @nthony View Post
    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.

  5. #20
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    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?
    Last edited by @nthony; 08-29-2007 at 11:08 PM.

  6. #21
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by @nthony View Post
    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...

    Code:
    $ 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.
    Last edited by brewbuck; 08-29-2007 at 11:27 PM.

  7. #22
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    I happen to have a Ubuntu disk on hand, can I use the grep utility from this as well?

  8. #23
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by @nthony View Post
    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.

  9. #24
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    Window's encoding (1252 I think my file was) won't intefere much with grep will it (its still ASCII right?)

  10. #25
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,235
    Quote Originally Posted by @nthony View Post
    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.

  11. #26
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    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...

  12. #27
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    "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

  13. #28
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    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)

  14. #29
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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

  15. #30
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Eh, find takes forever. Use
    which grep
    to find out the exact path of the grep binary found by the PATH mechanism.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Page 2 of 4 FirstFirst 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Faster C coding thanks to utilities?
    By rommegrot in forum C Programming
    Replies: 5
    Last Post: 04-25-2008, 02:34 PM
  2. How Do You Undelete A File?
    By Krak in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 06-02-2004, 12:23 AM
  3. Creating utilities for games.
    By RealityFusion in forum Game Programming
    Replies: 6
    Last Post: 04-12-2004, 07:31 AM
  4. Including
    By gvector1 in forum C++ Programming
    Replies: 2
    Last Post: 02-20-2003, 08:13 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21