Jump to content

RockSockDoc

Members
  • Posts

    8
  • Joined

  • Last visited

Reputation

0 Neutral
  1. 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! 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!
  2. 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.
  3. Title: No location specified when maximum path length is exceeded. Description of problem: When one encounters the Recuva error "Maximum path length exceeded", there is no helpful information provided. Which path length was exceeded? Was it a file in the source path? Was it a file in the destination path? What is the maximum path length anyway? Why does an Internet search come up blank on this error? Why isn't there at least a log file explaining the error in more detail? Version release: a. Recuva 1.46.99 b. WinXP Home SP3 c. Intel Pentium M, 1.75GHz, 1.0GB RAM How reproducible: A. Simply try to recover files which have a long filespec B. The error will pop up, and you won't have a clue which file caused the error C. In my case, that was one (or more) files out of 400K files Implications: 1. This is clearly a usability issue, and one of finesse 2. It's standard operation to report which file or which rule has violated the error 3. The problem is that, with 400k files, it's almost impossible for a user to find the exact file which is causing the problem Workaround: This bug forces the user into devising a sorting algorithm to determine which file is the culprit. However, complicating this workaround is the inability of Recuva to select blocks of files in a meaningful way. Sorting by path, which would normally be the most logical, doesn't work (due the the ambiguous nature of Recuva path reports). Worse yet, there is no numbering system; so one can't easily break the sort into 50K file chunks. Making matters even more unnecessarily complicated is the fact that Recuva's contiguous-block-selection mechanism is non standard. It's standard, on Windows, for a control+lmb (left mouse button) to select individual files (often non contiguous files). It's also standard, for a shift+lmb to select contiguous files. In Recuva, shift+lmb works for the "selection" of contiguous files; but it fails miserably on the contiguous checkbox for files. So one is forced to adopt this approach to make a contiguous selection of a block of 50K files: 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, 10. Then you repeat the process for the next 100K files - until finally - Recuva runs into the filespec which it is complaining about Expected results: It is expected of all software that an error points out where that error occurs so that the user can identify and fix the problem. The bug here is that the user is left in the dark as to where the problem lies, and only the most determined user will continue to use Recuva after such an ambiguous failure. The Recuva software is good; but this bug shows that it has not been thoroughly tested in a real world environment, with real users. Otherwise this bug wouldn't exist. So it behooves the developers to fix this bug to restore confidence in the product line. A secondary bug is the non-standard way that the checkbox selection occurs; and a tertiary bug is the lack of an dentification mechanism so that the user has a visual clue as to how many files are selected. Note: I do realize putting an actual number in the left-most column is problematic, due to the number of digits required for 400,000 files; so a report of the selected amount would be apropos. Additional information: Need to know how to recover table of contents for an external NTFS 150GB disk
  4. 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:
  5. 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. 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?
  6. 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! 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 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? Yes. Quite possible. You are probably correct in that assumption. Thanks. 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?
  7. 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 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! 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). 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?
  8. 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!
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.