Jump to content

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

Recommended Posts

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



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



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


Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...

Important Information

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