Need to know how to recover table of contents for an external NTFS 150GB disk

[RockSockDoc]

I must be doing something wrong as I have not deleted any files; it's just my table of contents on an external USB disk has gone bad due to a chkdsk /f operation because the file system wasn't recognized. [ Note: Recuva says the disk is: NTFS, 149GB. cluster size: 4096. file record size: 1024. ]

 

Everyone said Recuva on WinXP Home was the way to go, and I love CCleaner, so, I figured it's the way to go.

But I must be doing something wrong. Very wrong.

 

The first time I ran Recuva 1.46.919, I followed the Wizard defaults (my mistake), and, three days later (66 hours), it had recovered over 100,000 files FLAT!

 

I can't even *open* that WinXP directory, it has so many files, all of which are useless to me because all I want to do is recover the table of contents.

Scratch three days.

 

The second time I ran Recuva, I learned to check the button for "Restore folder structure", and to "Scan for non-deleted files" (as all my files are there, they have not been overwritten, and they have not been deleted). They just can't be found. Two days into that effort, my kid clicked the top right (since you can't close or hide the window), and all was lost (well, half was found, but all I want to do is recover the original tables of content).

 

NOTE: I call it the table of contents because I don't know if it's a MBR or if it's a FAT or what. What I mean is all the files are there, and undamaged; it's just the reference to them that is damaged.

 

My question:

Q: For my third attempt, do I have the settings correct yet (see attached screenshot) for simply recovering the table of contents?

 

Thanks for your help!

[Augeas]

Run 1: before you can recover files to a folder, you must have completed a scan. Did the scan complete? Did you select 100,000 files to recover? Did you just check the top box for select all? 100,000 files is not excessive for some users (but three days is).

 

Run 2: Scan for non-deleted files reads a valid file table where the front end has been overwritten with a format. If the file system was corrupted in the first place then this option won't retrieve your files. It sounds as if you were still running he scan on cancel.

 

Run 3: I wouldn't run Recuva at all. It appears that you have problems with the disk. What was the file system before the chkdsk? I should try to get a run of chkdsk to work OK before continuing with Recuva.

[RockSockDoc]

Did the scan complete?

 

I appreciate your help; and I will try to be accurate and responsive in turn.

 

Yes. All scans completed.

The quick scan found nothing so I had run a full scan, but I didn't know about the defaults so it took 3 days to complete (virus scanner was not turned off) where Recuva dumped 100,000 files into a single directory.

 

I can't even open this directory on Windows XP Home; but I can list it by using the DOS command line and using DOS syntax:

C:\> dir /s/a/l/on/b > c:\tmp\files.txt

 

Did you just check the top box for select all?

Yes. My initial mistake was to *not* check the box for keeping the file hierarchy on the first 3-day scan, and not to disable my anti-virus program (and that cost me three days elapsed time).

 

Now I know better!

 

Run 2: Scan for non-deleted files reads a valid file table where the front end has been overwritten with a format.

 

I did run a second scan, with three changes:

a. I turned off my virus scanner (Avast)

b. I checked the Recuva option for non-deleted files

c. I turned on the Recuva checkbox to preserve the file hiearchy

 

This second run has found over 400K files (so I'm a bit worried why scanning for undeleted files finds *more* files than the first scan, which only found 100K files).

 

What was the file system before the chkdsk? I should try to get a run of chkdsk to work OK before continuing with Recuva.

The file system is NTFS.

The damage sequence that occured is this:

1. I was backing up lots of data (because a Windows PC was running slow) to the NTFS USB drive;

2. I disconnected that NTFS external USB disk and rebuilt the Windows XP Home OS on the slow PC (this fixed the PC problem);

3. When I reconnected the USB disk, it was unrecognized (on multiple machines); so googling, I found a MS support KB176646 which said to run "chkdsk /F" so I did.

4. Immediately after the chksk, the USB disk was recognized (on multiple machines); but no files were visible.

5. I asked what tool to use (e.g., alt.comp.freeware NNTP USENET newsgroups) and people said to use Recuva (so that's what I'm using).

 

The problem I have, since each run takes days, is to learn the use model correct *before* I run Recuva.

 

Here is the result of a quick scan:

 

Here is a result near the end of the first stage:

 

Here is the result at the end of the second stage:

 

And here is a result near the end of the third stage:

 

And, this is where I am now:

 

I'm asking for use-model advice mainly because I don't want to make any more mistakes in the next step to recover all my files hierarchically.

 

Since Recuva is so touchy (any wrong move and it's a day or two later before I can recover), I'm trying to figure out (ahead of time), how to recover select files (e.g., turbotax results), and then, after the select files are recovered, how to recover all the files back to where they were before the chkdsk was run.

 

All the files should be there; it's just a master table of contents that got corrupted.

 

EDIT:

I clicked on the "Recover" button, and, after a few minutes, I got this error:

Error: Maximum path length exceeded

 

But, strangely, Recuva doesn't tell me which of the 400,000 files is the one that I should uncheck!

 

QUESTION: How do I get past the error that one (or more) file specs is too long for Recuva?

[Alan_B]

how to recover all the files back to where they were before the chkdsk was run.

I hope you do not mean that.

 

You recover files to a different drive from the one that is damaged.

Only when you have completed recovery and have no need for any future attempt should you consider formatting/writing to the damaged drive.

 

Is it possible that your 400,000 files have only 100,000 unique file names but many are repeated in different folders and paths ?

and your initial recovery did not preserve the path structure so different instances of the same name got replaced as Recuva proceeded.

[RockSockDoc]

I appreciate your help - and I realize nobody has to help me. I will do my best, as I am on many forums, to give back and pay it forward, at the very least with detail, so the next person who follows in our footsteps benefits.

This alone makes any of your efforts leveraged to others, as it should be.

Thanks!

 

You recover files to a different drive from the one that is damaged.

Yes. Of course. I am sorry if I mis-represented the fact that I'm trying, hard as I can, not to touch the original drive.

I even made a Linux "dd" backup of the entire drive onto another drive (but I was afraid to wait the three days to see if Recuva worked on it):

$ sudo dd if=/dev/sdc1 of=/mnt/image.dd bs=1M
==> 152625+1 records in
==> 152625+1 records out
==> 160039240704 bytes (160 GB) copied, 9750.86 s, 16.4 MB/s
$ ls -l
==> -rwxrwxrwx. 1 root root 160039240704 Jun 1 12:13 image.dd

 

Only when you have completed recovery and have no need for any future attempt should you consider formatting/writing to the damaged drive.

Yes. I fully understand. The only way I'm going to write to the original (bad) drive is if I make a mistake; I repeat that I have absolutely no intention or desire to screw around with the original data that is on the drive.

QUESTION: Will Recuva work with the image.dd file created with the Linux "dd" command?

 

Is it possible that your 400,000 files have only 100,000 unique file names but many are repeated in different folders and paths ?

Yes. Quite possible. You are probably correct in that assumption. Thanks.

 

your initial recovery did not preserve the path structure so different instances of the same name got replaced as Recuva proceeded.

Again, quite probable. Thanks for explaining this.

 

Right now, I'm going through the horribly difficult (actually pathethic) recovery by file name (e.g., search strings of tax, resume, powerpoint, pdf, etc.) to recover files simply because a complete recovery bombs out with the error that a filespec is too long. This is such a common happenstance that there must be a way to get around that error.

 

QUESTION: How do I get around the error that one (or more?) filespecs are too long for Recuva?

[Andavari]

But, strangely, Recuva doesn't tell me which of the 400,000 files is the one that I should uncheck!

 

I don't know if it's a file name length problem, or the amount of files you're trying to recover. What I'd try is to recover the files in smaller groups instead of trying all 400,000 at once.

[RockSockDoc]

I don't know if it's a file name length problem, or the amount of files you're trying to recover.

 

Thanks for sticking with me. I suspect it's a path-length bug in Recuva because there was no indication that any particular filespec was too long for NTFS.

I don't doubt there may be a filespec too long for Recuva, but, Recuva, for its part, should identify the offending file so that a user can quickly omit that one filespec.

Seems like a bug anyway (is there a way to file a bug report against Recuva so that it is fixed for others in the future who will inevitably run into this problem?)

Note: I do realize Recuva is freeware - but that doesn't mean the development team doesn't want to know about use-model bugs.

 

What I'd try is to recover the files in smaller groups instead of trying all 400,000 at once.

 

Yes. I agree. Sigh. I will try that. The use model in Recuva for identifying blocks of files is strange, at best, mainly because the file name is NOT the way to identify things when you wish to recover the entire disk.

Only the file paths would be meaningful in that case (since there are 400K files scattered about, many with the same names, and certainly they were never organized by file name - but by directory tree).

Unfortunately, while all the files are recoverable, the directory tree in Recuva's output seems badly mangled (so sorting by directory tree is, essentially, useless in Recuva).

 

For example, many directories show up as "E:\?\", which seems to indicate they were at the root level but I store NOTHING in the root level of a disk, so, that Recuva Path can't possibly be correct.

I guess there may be nothing Recuva can do about that - as the master file table must have been mangled.

 

Likewise, a ton of files show up in the Recuva path of "E:\?\.svn\", which again is wholly inconceivable; so Recuva can't be used to reliably sort by directory tree in my situation.

That's sad, simply because that's how almost all file systems are organized.

 

So, I'm stuck with saving by block, but sorted by file name.

Note: I used to work in QA for a software company, so, I'm very familiar with GUIs and use models. Give me a few days with Recuva, and I could file a dozen enhancement requests for an improved GUI that would benefit everyone!

 

The other use-model problems that make Recuva difficult to save by blocks of, say, 50,000 is the lack of a numbering system on the left-hand side. So it's hard to tell what you've saved (although Recuva does have a nice automagic feature of not checking items that were already saved prior).

 

Luckily, Recuva does seem to work when I have a specific file name that I'm looking for.

 

One strange use model feature that is a bit non-standard is how Recuva implements the left mouse button (LMB) selection, specifically, the Windows Shift-select versus the Control+select features of Windows:

a. In Recuva, Control+LMB on either the file names or the checkbox, selects individual files (which would take forever for 400K files)

b. In Recuva, Shift+LMB on the file names does correctly select contiguous blocks of file names; but, Shift+LMB on the checkboxes does not select contiguous blocks of files.

c. Yet, in Recuva, if you Shift+LMB a block of file names, and then left click on the checkbox at the start of that selected set of file names, then (and only then), the contiguous check boxes are selected.

This is weird.

 

So, my detailed approach to recovery (since the bug exists that one or more filespecs is too long for Recuva), is currently the following (please improve if you can so all benefit):

1. I sort the scan results by Path (yes, it's problematic no matter how I sort these results);

2. I left-click on the file name (not on the checkbox!) of the very first scan result (I wish group selection would work with the checkbox, but it won't);

3. I scroll down approximately 100K files (it's crazy but you have no way of knowing where you are logically so this is just a mere guess);

4. I press the Shift key, and then left mouse click on the file name (this selects a contiguous block of about 100K files by name but not by checkbox!);

5. To get the contiguous checkbox, I carefully position my mouse on the first checkbox of the contiguous selection and shift left click on that checkbox;

6. That careful procedure will now have the checkboxes next to that contiguous selection of files all selected;

7. You actually have no idea (at this point) how many you've selected, as you can't manually count 100K files this way (there should probably be a count at this point showing up in the GUI);

8. At this point, you can press the "Recover" button;

9. Then you have to go back to figure out WHERE you last left off, and then you repeat the process for the next 100K files - until finally - Recuva runs into the filespec which it is complaining about;

10. If you know of a BETTER way to figure out which filespec is causing the error that is preventing Recuva from brecovering the desired files?

 

QUESTION: How do we file a bug report that the too-long filespec error gives no indication of the filespec that caused the error?

[Alan_B]

I suggest that an empty drive X:\ with no folders or files is a suitable target for files rescued from drive D:\ (for example)

 

If you recover the file

D:\A VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY LONG PATH\A VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY LONG FILE NAME

TO

X:\A VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY LONG PATH\A VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY VERY LONG FILE NAME

Then since the original file and path on D:\ are short enough to NOT violate Windows restrictions,

then the corresponding items can be save to X:\

 

If however you identify a rescue attempt by using the folder

X:\First recovery attempt on 1st April 2013\

then you reduce the length of the folder and filename length that can be rescued and appended

 

If you use a Drive that already holds other folders and files then use the shortest possible name for your parent folder, e.g. restore to

X:\#\

[RockSockDoc]

If however you identify a rescue attempt by using the folder

X:\First recovery attempt on 1st April 2013\

then you reduce the length of the folder and filename length that can be rescued and appended

 

Ah. Again you've explained what seemed inexplicable! Thanks.

I'm in the middle of my piecemeal approach, trying about 50K files at a time, and will attempt what you say on the next pass.

So far, I've recovered roughly 200K files using this piecemeal effort - a Recuva log file showing what filespec it didn't like would have been a lot easier!

Still - your point is certainly understood: If the file name is valid to start with, then putting it at the TOP of the disk with a short filespec should still be valid

 

Here is my latest 100K file piecemeal attempt - but I must be very careful with my Control-Shift selection sequence in this process:

[Andavari]

Seems like a bug anyway (is there a way to file a bug report against Recuva so that it is fixed for others in the future who will inevitably run into this problem?)

 

In the bugs area you can post a bug report:

http://forum.piriform.com/index.php?showforum=17

[RockSockDoc]

In the bugs area you can post a bug report:

 

Thanks. As my paying it forward, I filed a detailed bug report so that the Recuva product can be improved.

- Bug Report: Error: Maximum path length exceeded (missing log information)

I tried with a location of J:\x and it seems to step past the error - so - the bug apparently shows up on the destination filespec,and not on the source filespec.

Your help was instrumental in overcoming this bug!

i doubt a typical user, without your assistance, could easily overcome this bug - hence it's important to solve it for future users.

[Augeas]

Well, there are least 14 hits for maximum path exceeded on this forum (many in the bug reporting forum), and the proposed resolution. I haven't the time at the moment to go into all the points you raise, but in my opinion Recuva is principally a file recovery application, and you'd possibly be better off using something designed to recover full disks. Don't ask me what, as I have no specific experience in that. But I'm sure others have.

[Andavari]

Thanks. As my paying it forward, I filed a detailed bug report so that the Recuva product can be improved.

- Bug Report: Error: Maximum path length exceeded (missing log information)

I tried with a location of J:\x and it seems to step past the error - so - the bug apparently shows up on the destination filespec,and not on the source filespec.

 

I at least understand more what was happening, and since you're on WinXP which I also use that can in of itself be an issue during recovery, or when just doing a daily backup of files.

 

One problem which is an OS problem is WinXP's "C:\Documents and Settings\...." folder location can end up getting files stored so deep into it with crazy lengths that can trip up some programs which haven't devised a way of working around paths/names that are just way too long such as some zipping software unable to zip or unzip backups from that path, etc.

[RockSockDoc]

Recuva is principally a file recovery application, and you'd possibly be better off using something designed to recover full disks.

After letting Recuva run for a week, I have to agree.

Recuva is a GREAT single-file (or small number of files) recovery program.

But, it's really almost useless as a disk-recovery program, simply because it doesn't do the basics (i.e., MBR or FAT recovery) and it takes forever (and I mean forever - we're talking many days) to grind through a rather small USB disk (admittedly on a Dell B130 Inspiron, which isn't the fastest machine on the planet). In the end, my hierarchical recovery failed, mainly due to the fact that the machine inexplicably rebooted, four days into the recovery. Sigh.

 

I'll use the second-most recommended software, to see if it works for my needs.

[MODERATED](and its companion program, [MODERATED])

Wish me luck!

 

I at least understand more what was happening

Thanks for all your help! I do very much appreciate it, and hope others will benefit from our shared experience.

When/if I recover the lost data, I will try to update this thread with the solution!

 

Thanks!

Edited June 11, 2013 by Nergal

[Nergal]

RockSockDoc this is a software's official forum. pPease only let moderation staff recommend/link/mention other softwares, especially competition.

Edited June 11, 2013 by Nergal
clarification