Max path length Exceeded in Recuva Bug Reporting Posted January 5, 2012 Having spent several hours creating a selection set from a list of 1.8 million files, I did not need to see "Maximum path length exceeded" when I finally hit the Recover button. As 'justtryintoHelp' has suggested one or more file names is the likely culprit. In my case, that did not help too much.... which of the many needles in my giant haystack was the culprit. I had exported a list of 'deleted files' to a text file. Importing that list into MS Access and running a couple of queries - one to compute the filename length and another to sort on that and the filename - pretty soon showed me that 20-odd files of type jpg had names of 255 characters. This leaves no room for a legal path. I suspect it might be a minor fault in the process that generates file names during the scan. Be that as it may, chasing down each of the long file names in the Recuva listing identified 2 out of the 'illegals' that were ticked for recovery. By unticking those two, the Recover process started. (Might be useful if Recuva could itself identify the entry or entries that are causing the problem - save chasing off to Access etc.) The progress screen was quite exciting. At first it proceeded normally, showing a percent completion figure, a number of files written and an estimate of about 10 minutes to completion. After about 20,000 + files had been copied, the % completion started flickering semi-randomly anywhere between 116% and 124% and beyond, and the time to completion drifted out to 17 days and so on. Time to panic or make some tea, so I made tea. When I came back, the screen was reporting task completed: 45,254 files in 913.83 seconds. I suspect the progress screen is using an integer variable, where in this case a 'long' would be better suited to volumes in excess of 32000. But who cares? It all came good in the end.