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?