Automatically unselect (or show) files causing "Max Path Length" error

[jbs]

The issue has been mentioned elsewhere, but not a specific suggestion for a fix as far as I can tell. Recuva is the best program I've used for file recovery but occasionally a drive I use it on has one or more absurdly long file names and leads to the "Max Path Length Exceeded" error.

 

It would be WONDERFUL if Recuva could offer any one (or more) of the following solutions when that message is generated. I've listed them in descending order of attractiveness imho:

1. automatically rename the file to make it path compliant
   
2. allow me to rename the recovered file to comlply with the path length
   
3. filter the list to show the files which are causing the error, allowing me to rename them manually
   
4. filter the list to show the files which are causing the error, allowing me to unselect them but still know what they are
   
5. automatically unselect them and proceed with the recovery
   

As it is, for restores tens of thousands or hundreds of thousands of files, navigating through to find which ones are causing the problem is not always possible. Any recommendations on how to work around this would be greatly appreciated!T

 

Thanks for an AMAZING piece of software!!!

[Nergal]

I believe that the fix is to (at least temporaraly while recovering the offending items) turn of the option to "restore folder structure"

[jbs]

I believe that the fix is to (at least temporaraly while recovering the offending items) turn of the option to "restore folder structure"

 

Thanks for the reply. I know that would technically resolve it, but at the expense of dumping perhaps 200,000 files in one folder :-)The problem is that Recuva doesn't tell me which are the offending files and allow me to just select those for a restore without folder structure. It's all or nothing, or else going page by page through thousands of pages trying to uncheck the long files.

 

If I'm misunderstanding the workaround I apologize and would love to know more. Thanks again for the reply

 

--Jason

[Augeas]

Perhaps it's better to approach this in another way. I have never had this problem, by the way, so this is all conjecture.

 

I assume you are running a normal scan and recovering to a different partition or drive. If you're running a deep scan then that's not too important, but recovering to a different drive certainly is. I can think of two ways to try to crack this, simplest first.

 

One could presume that the problem arises when trying to construct a path for the recovered files on the recovery drive. The combination of the existing path to the files and the path they're being recovered under exceeds the permitted path length. It may well be that the recovery is being attempted to an existing path on the recovery drive such as C:\Documents and Settings\My Name\My Documents\Recovery. This is already a sizeable chunk of path length. You could try setting up a new folder on the recovery drive under the root called C:\R, for instance. This one-letter directory will give the shortest path length to recover to. Well, just C:\ would be shorter, but it would make a terrible mess of your root directory. Run the recovery to folder R with 'Restore folder structure' checked.

 

If that doesn't work then keep R as the recovery folder. Look at what you're trying to recover. Recuva will build a path from the deleted files back to the root, passing through many folders. These folders will not (all) have been deleted. So you might be trying to recover files deleted from C:\Documents and Settings\My Name\My Documents\These_Files_Have_Gone where only the Gone folder has been deleted. Perhaps Gone is still there. So temporarily, and keeping a note of what you have done, rename the longest named live folders to single-byte chars, such as C:\Documents and Settings\My Name\My Documents\A. The folders to rename, and the extent of the renaming, is up to you. Then run the recovery to folder R as in method one. Recuva will build up the path from the existing shorter folder names. As you're recovering under a path of only a few bytes long, you don't have to rename many folders.

 

After a successful recovery you can rename the source drive folders back again, then copy the recovered folders back to the source drive. Or some variation of the above.

[Super Fast]

This sounds long. Example, perhaps? Have found that brevity helps!

 

Perhaps you mean to recover to C:\Recovered instead of C:\Documents and Settings\User\My Documents\Etc?

 

My eyes bled trying to read & comprehend all the suggestions for renaming & folder conventions & etc. LOL!

[jbs]

I might be mistaken but I think in some cases the files being recovered are themselves longer than the 255 characters. I know that normally shouldn't be possible (which is why I caveat that I might be wrong) but I know for example that TeraCopy will occasionally fail to copy something because of the >255 limit and I'll switch over to FreeFileSync and it will handle it fine. I'm not familiar enough with the rules and any exceptions to know why that might be, I just know it is.

 

Next time it comes up I'll certainly try the trick of restoring to c:\r\ and see if that works, but can anyone confirm that certain file systems may already have more than 255 characters in the path/name?

[Alan_B]

I might be mistaken but I think in some cases the files being recovered are themselves longer than the 255 characters. I know that normally shouldn't be possible (which is why I caveat that I might be wrong) but I know for example that TeraCopy will occasionally fail to copy something because of the >255 limit and I'll switch over to FreeFileSync and it will handle it fine. I'm not familiar enough with the rules and any exceptions to know why that might be, I just know it is.

 

Next time it comes up I'll certainly try the trick of restoring to c:\r\ and see if that works, but can anyone confirm that certain file systems may already have more than 255 characters in the path/name?

Use the DOS command

DIR /X

That shows both short (8.3 format) and long names for files and folders.

I do not KNOW if this is the case, but perhaps TeraCopy is unable to use the short 8.3 format names, whilst FreeFileSync may.

You can pack a lot more shortened names into 255 characters.

[hazelnut]

Just a thought and slightly off-topic, Roadkil's Unstoppable Copier can handle up to 4096 characters

[Augeas]

Yes, but we are trying to recover a deleted file using Recuva, and under NTFS?

 

The max path/file name I can create (XP, but the rule appears to be NTFS based) is 259. The annoying thing is that when I try to recover this file to an even longer path I get no error message at all, just a 1 file recovered in n secs. The folder structue has been restored but the last folder and the file haven't been recovered, just gone into thin air. I'll try with a shorter file name and a longer path name.

 

No, still no error message, just drops the folders/files that exceed the length max. Annoying.

 

Ha! Cracked it. If one selects a group of files to recover (instead of a solitary errant file) the Maximum Path Length Exceeded message appears.

 

I then created a folder under the root of the recovery drive, as c:\x, and the group of files recovered OK. Actually I had to shorten one of the folder names in the source drive path to get this to work, it seems that you can't squeeze the last drop out of the path length when doing the recovery. So, to be brief as some have requested,

 

1) Recover to a single-byte folder name under the root, such as c:\r

2) If this fails rename long folder names on the source drive to single-byte names

3) Rename folders in 2) back again after recovery.

[hazelnut]

Good info there Augeas

 

(I mentioned Unstoppable Copiers max character size as a comparative to the TeraCopy and FreeFileSynce that were mentioned about ..off topic I know)

[webbed_in_portland]

I dont know if anyone is still monitoring this post, but i recieved the same error when trying to recover files...i alleviated the issue after i unchecked files that had exceptionally long file names...most turned out to be image files that had a long string of tags in their name...unchecked those and tada, no problem, even with the restore file structure option selected...

[Damien barifon]

Try to long path tool software. It is very helpful. 

[Nergal]

Threadcomancy stopped