Jump to content

Proposed Solution to "Maximum path length exceeded" Error.


Alan_B

Recommended Posts

I understand that the actual error is NOT what is reported.

The problem is excessive length of Path PLUS LENGTH of Filename.

The problem is ACTUALLY with the destination to which recovered files are saved,

so saving to the root of X:\ will be more successful than saving to

X:\Long Folder Names Are My Habit\

 

Unfortunately Windows may break the rules and create path+name lengths that a user (and Recuva) is not allowed to do.

Such items must be excluded from any attempt to save complete with original path.

 

This should give you a list of all the Path+Filenames, starting with those that are so long they should be excluded

 

Download SysExporter from

http://www.nirsoft.n...ils/sysexp.html

 

Find deleted files (I am using Recuva64.exe v1.47.948.)

 

Launch SysExporter.

Select from the "Title" column Piriform Recuva

and choose from the "Type" column "List View".

After a long delay the bottom half of the display corresponds to the Recuva display,

then use Menu "Items" / "Choose Columns" and reverse the order of Filename and Path,

uncheck all the other boxes, and click OK.

Menu Items / Select All

Menu Items / "Copy Selected Items (Tab delimited)"

 

Launch Notepad and use Ctrl-V to paste the contents of the paste buffer into Notepad,

and save as a file Report.txt to a convenient folder (I use E:\Tools\Piriform\Recuva\v-1-47\)

Now create in the same folder the file

"Long.BAT" and copy into this

sort /R /+250 report.txt > Long.txt

Launch Long.BAT

and it will create the file Long.txt,

EDIT :- Enhancement that adds a calibrated ruler as a "header" to measures the length of a folder path plus name

"Header.BAT" and copy into this :-

@ECHO OFF & setlocal EnableDelayedExpansion
SET /A SORT=247
SET /A MAX=259
ECHO Script %~f0 revised %~t0
IF "%1"=="" CALL :S %SORT% & GOTO :EOF

:S
SET "STR=" & FOR /L %%N IN (0,10,%MAX%) DO SET "STR=!STR!....'....;"
SET /A NH=%1-1
SET /A NG=%MAX%-1
SET "STR=!STR:~0,%NH%!S!STR:~%1,%MAX%!"
ECHO !STR:~0,%NG%!M :- S(ort)=%1 M(ax)=%MAX% > REPORT.LST
MORE /T0 REPORT.TXT | sort /R /+%1 >> REPORT.LST

and this will create the file REPORT.LST that commences with the calbration ruler followed by a sorted list

which will show at the top of the list all the path+files which exceed 247 characters in length.

 

PLEASE NOTE

The output list of items is sorted in two sections.

The top section are all path-file-names with a minimum length of 247 characters,

followed by the section for all path-file-names with a miaximum length that is less than 247 characters.

For a different split just change the number in the second line which reads "SET /A SORT=247".

e.g. if you wish to "restore with folder structure" to a pre-existing path that is 20 characters long,

you cannot then restore anything that was more than 239 characters long, so a suitable command would be

SET /A SORT=227

You can also change the number in the third line if your system can use longer path-file-names than the 259 limit of my system

 

END OF EDIT

 

The actual limit for Windows is 259 characters (plus NULL terminator)

Whilst the NTFS limit is 32,000 character.

http://www.codinghor...s-too-long.html

I wonder what the Linux limits are :rolleyes:

 

EDIT SUPPLEMENTARY :-

After deselecting all items that are responsible for a "Maximum path length exceeded",

you can restore with folder structure,

after which the few which were selected can be restored without structure,

and then you can use Windows Explorer to shorten their names of shorten the restored folder strucure and then move those files as you wish.

 

N.B.

You will find a worked example in my recent bug report :-

http://forum.pirifor...036#entry237168

 

P.S.

I am shattered after debugging the clever bit of code

SET "STR=!STR:~0,%NH%!S!STR:~%1,%MAX%!"

I am in no condition to explain how that works, but these links will help you to also get a headache if you are interested

http://www.dostips.c...anipulation.php

http://www.dostips.c...ets.RightString

http://www.dostips.c...pets.LeftString

http://www.dostips.c...ppets.MidString

 

and there is expert advice available at

http://www.dostips.c...ewforum.php?f=3

 

CORRECTION

Some how stray text "with folder structure" became embedded in the code.

Now fixed at 20:18 15/07/2013

Link to comment
Share on other sites

  • Moderators

Although I don't have the error to test it on properly, this all pans out and produces the files as you explain it above Alan ...

 

post-8751-0-17028300-1372626108_thumb.jpg

 

... except that Recuva has to be in "List View" mode for that option to appear in the SysExporter upper window.

 

I have Recuva configured to display scan results in "Tree View", which means "List View" wasn't available as a choice in SysExporter.

 

Probably obvious, but maybe less experienced users may not latch on to that.

 

This would probably be worth pinning until a fix is found but I'm wondering if you could provide a screenshot of a successful outcome showing the actual errant "Path Length Exceeeded" files displayed at the top of the "Long.txt" file?

 

Or if any member has had success or not with this, would they please post their observations here?

:)

Link to comment
Share on other sites

  • Moderators

I can add Alan, that your topic and the subsequent discussion on it, has prompted a response from the developers in so far that a "fix" for this issue is being worked on, and should appear some time in the near future.

 

How near is impossible to say at the moment, but I will say that your efforts toward this and the time you must have put in is very much appreciated.

 

As far as I'm concerned I'll bookmark this thread for now, and point any folk with this problem to it, and hope it may be of some help.

Link to comment
Share on other sites

Thank you Dennis.

 

I have been working on a my initial proposal in conjunction with a new script to create recovery targets with lengthy names for path + file.

It has been a painful processes, iteration between two scripts to ensure functionality.

 

This may be useful to the developers and Beta testers.

It is the lengthy creation script which I call BIG.BAT. :-

Save this to any folder on any drive and run it, and it will ATTEMPT to create on the same drive a long path with 7 files

but windows does NOT allow the existence of the longest name which is FF-22----PFP-----F.INI

 

@ECHO OFF
SET "FIFTY_4=[----------------------FIFTY_4-----------------------]"
SET "MY-PATH=\-#\$\(1%FIFTY_4%1\2%FIFTY_4%2\3%FIFTY_4%3\4%FIFTY_4%4)"
MD "%MY-PATH%"

ECHO A %TIME% A > "%MY-PATH%\AA12.INI"
ECHO G %TIME% G > "%MY-PATH%\GG12.INI"
ECHO B %TIME% B > "%MY-PATH%\BB-18----TBT-B.INI"
ECHO C %TIME% C > "%MY-PATH%\CC-19----SCS--C.INI"
ECHO D %TIME% D > "%MY-PATH%\DD-20----RDS---D.INI"
ECHO E %TIME% E > "%MY-PATH%\EE-21----QEQ----E.INI"
@ECHO ON
ECHO F %TIME% F > "%MY-PATH%\FF-22----PFP-----F.INI"
@ECHO OFF
ECHO Expect Error message if "F %TIME% F" is written to excessive length of Path + FileName.
DIR "%MY-PATH%"\*.INI | FIND ":"
TYPE "%MY-PATH%\EE-21----QEQ----E.INI"
ECHO As at %date%%time% the above is the text within the file "EE-21----QEQ----E.INI"
TREE \-# /F
PAUSE
RD /S /Q \-#\$
TREE \#- /F

 

After lunch I will provide further documentation and enhancements to my first post.

 

Regards

Alan

Link to comment
Share on other sites

  • Moderators

Thanks Alan, I'll watch out for that, and try not to make it too complicated.

:)

 

 

EDIT:

 

You've put so much work into this Alan, and in view of the fact that we have absolutely no other workarounds or fixes for this issue (as far as I'm aware), I've decided to pin it until a proper fix is introduced.

 

The process outlined by you is a perfectly safe one for any member of any experience level to try without doing any harm to their machine or files, and if it enables just one person to facilitate a recovery of valuable files they would otherwise have failed to recover, then it's a worthwhile exercise.

 

If I can do it and come up with a list of files, then I think most people could.

Link to comment
Share on other sites

Thanks Dennis.

 

I regret delayed return from lunch due to household chores that were imposed from on high.

 

DOCUMENTATION :-

 

PLEASE NOTE that the script pauses after creating the folder structure with files,

and only deletes the structure with files when you hit any key.

Until they are deleted you can use Recuva to detect and restore these undeleted files to another drive.

You can then use a folder comparator utility to confirm the accuracy of of Recuva.

 

Big.Bat

Attempts to creates 7 files :-

 

AA12.INI

GG12.INI

BB-18----TBT-B.INI

CC-19----SCS--C.INI

DD-20----RDS---D.INI

EE-21----QEQ----E.INI

FF-22----PFP-----F.INI

 

The last file FF-22----PFP-----F.INI is NOT created,

because the length of the path name plus the length of this file name exceeds the 259 character limit imposed by Windows.

 

Using the RECOVER WITH FOLDER STRUCTURE option I fully expect success for :-

All of the 6 created files when restoring to the root of X:\, and

All of the first 4 shorter files when restored to X:\Y\

 

Unfortunately Recuva complains "Maximum path length exceeded" unless I exclude EE* and DD* from root of X:\

and additionally CC* is too long for restoring to X:\Y\

 

Windows has a limit of 259 characters

Recuva is crippled with a limit of 257 characters

 

I have further work in hand which I intend for this afternoon - if I get time off for good behaviour :)

 

SUGGESTION TO PIRIFORM DEVELOPERS

Look in the code for excessive use of the character '\'

 

You need a MINIMUM of a single '\' separator between each segment of a folder structure

Windows will forgive and ignore repetitions of '\' when actually creating the path,

BUT the syntax error checking may well include the extraneous characters when considering the upper limit of 259 characters plus the null terminator.

 

This script demonstrates that extraneous characters are ignored so far as creating path structures on drive W:\

@ECHO OFF
ECHO(
SET "#DRIVE=W:"
SET "#BASE=%#DRIVE%\AAAAAA\"
SET "#PATH=%#BASE%\BBBBBB\"
SET "#NAME=CCCCCC.TXT"
SET "#_Drive_and_Path_and_File_Name=%#PATH%\%#NAME%
MD %#PATH%
ECHO THE TIME IS %TIME% > %#_Drive_and_Path_and_File_Name%
REM TREE %#BASE% /F
SET #
ECHO THE OUTPUT PATH AND FILE STRUCTURE IS :- %#_Drive_and_Path_and_File_Name%
DIR %#BASE%\*.TXT /S | FIND ":"
TYPE %#_Drive_and_Path_and_File_Name%
RD %#BASE% /S /Q

Link to comment
Share on other sites

Hi i also having maximum path problem

i wonder why piriform haven't fix this problem since i googled it and there are dozen post here about the same issue over the years

 

anyway i'm trying to recover about 500k files (2tb drive)

i'm using win 8 x64, i7-2600, 16gb ram

one of my drive was deleted by a deduplication program

so im trying to recover all the files and restore it on an empty drive

 

i tried to recover per folder so i can find the file/folder that exceed the length but that can't be done since recuva hangs everytime i i highlight a bunch of files,

 

i also see some people suggest to uncheck the restore folder structure but i can't do that since there's about 500k of file and it would be hard to categorize manually

 

so i tried what you do in first post but the problem is, there are no recuva listview type in the sysexporter

 

i already configured recuva to be in listview, so is there something i do wrong here?

i use the sysexporter 32 and 64 bit and it the same.

K1Mht0S.png

thanks

Link to comment
Share on other sites

I am using the 64 bit Recuva and 64 bit SysExporter with 8 GB of RAM.

 

SysExporter has 6 menu pop-downs at the top

Choose "Filter" and make sure that the "ListView" is ticked,

and look for this to be added below other programs.

 

If this does not resolve the issue after closing and restarting SysExporter,

then I suggest that you cancel the DEEP SCAN mode.

It will save you time,

and we may then have a common basis for comparison/discussion.

 

It takes my system 33 Seconds for a normal (NOT DEEP) scan to analyze 742 GB with 385,698 files.

Your system takes 40 times as long for twice the size - hence I guess you used DEEP SCAN.

 

Please note that when I select to display the contents of the 385,698 items under ListView then SysExporter freezes for perhaps 5 minutes whilst extracting all that data from Recuva,

but nothing crashes and the data transfer is successful.

 

SysExporter MAY lose the ListView capability when Recuva is in DEEP SCAN mode.

I do not have the patience to double check whether I simply did something wrong.

Link to comment
Share on other sites

Please note drastic revisions to the first post.

 

The new code "Header.Bat creates at the start of the output list.a very long header line that concludes with

;....'....;....'....;....'....;....'.S..;....'...M :- S(ort)=247 M(ax)=259

 

This allows you to see the "Sort Boundary" that distinguishes between

the upper section of results that reach or exceed 247 character length,

and the lower section that are less than 247.

Link to comment
Share on other sites

Please note that somehow a stray chunk of unwanted text appeared when I posted Header.BAT in the first post.

This has now been corrected to be the same as my original code.

Link to comment
Share on other sites

  • 10 months later...

cxs

I understand that the actual error is NOT what is reported.
The problem is excessive length of Path PLUS LENGTH of Filename.
The problem is ACTUALLY with the destination to which recovered files are saved,
so saving to the root of X:\ will be more successful than saving to
X:\Long Folder Names Are My Habit\

Unfortunately Windows may break the rules and create path+name lengths that a user (and Recuva) is not allowed to do.
Such items must be excluded from any attempt to save complete with original path.
 

The actual limit for Windows is 259 characters (plus NULL terminator)

Whilst the NTFS limit is 32,000 character.
http://www.codinghor...s-too-long.html
I wonder what the Linux limits are :rolleyes:

The linux limit is 4096.

 

Creating a pathname longer than 260 characters is trivial.

 

Also when recovering files, the length of the recovery folders name is added to the original paths, so hitting the limit is quite possible, for example c:\foo\bar becomes f:\recovered_files\foo\bar.

 

Working with long paths is no black magic (Total Commander for example can work with them and many other applications).

 

Therefore please consider fixing this issue in Recuva.

 

Regards,

David

Edited by Augeas
Thread closed due to persistent software spammers
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

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