Jump to content


  • Posts

  • Joined

  • Last visited


0 Neutral
  1. 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.
  2. First use of Recuva (1.42.544) - pretty straightforward, nice simple interface. Friend of mine, not PC-savvy laptop user, had a bit of trouble when a Windows Update failed in some way (he remembered no details). On restart he was presented with a confusing screen and he latched on to the word "recovery" as being a safe haven and press the F11 key expecting normal service to be resumed. Instead, what happened was that his machine was restored to factory condition by the automatic system restore "service" built into the laptop. At which point he knew he was really in trouble. I installed Recuva onto one of my boxes and pulled his 320GB drive (he hadn't tried much/anything after his misfortune had been converted to full-on disaster) from the laptop and connected the drive for Recuva to have a look at. Set the thing to run a deep scan and went out for a game of squash. Some time later I had a look at the machine. Didn't have a good time estimate - it had initially been quoting 60+ minutes, but I didn't really care, since I wasn't planning on sitting there. The scan had found appr 1.8 million files. My objectives were: 1. try to get a good fix (the names, dates, sizes) on all the user-significant files that were deleted 2. try to get as many user-significant files undeleted as possible. 3. rebuild the machine into his 'usual' desktop and app specification. 4. load back any/all recovered material Before acquiring the laptop, he was using a desktop machine - which is still in service. Many of his files were copied from that machine. The results from (1) above would allow him to see which of the irrecoverable files were actually still available to him from the old machine. Also that same list could focus his attention on which files he would urgently need to 'regenerate'. When I went to use the "Save List to Text file" pop-up option I discovered a couple of surprises. First was that the format/content of the generated text file did not match the on-screen display. Most particularly the "State" info seemed to be absent. The second surprise was that the generated file did not reflect the current 'filter' (at one point I set a filter of "*.odt") ... came out at 102MB. I had hoped to prepare several listings, so that he could focus on text documents (.odt, .doc etc) separately from images and so on. This needed to be doable 'offline' since it was all going to happen 'after the event' - i.e. I would salvage whatever I could and proceed with the rebuild, and he would do the debris sorting after that. Equally, the Recover button does not seem to be limited to the current filter. For example, a ticked selection is made from a *.odt start point and the chosen items written to a folder. Then the filter is changed to *.doc and another subset of that is ticked. The Recover button then writes all of the selected .doc files PLUS all of the previously selected .odt files. Not quite what I would have expected. While typing the filter text, there were considerable delays between each character. The filter is clearly trying to operate in "real time", dynamically filtering the display as each character is typed. With 1.8 million items in the start list, this was painful delay. Might be preferable to suppress this feature or at least make it an option. Extensions to the filter would also be very helpful. For example, to filter in/out based on "State", "Date", "Size" would be very handy. If I were looking for movies, I might also want to exclude anything less than 200MB. OK, I guess the list could be sorted by size, but how could I then reset to the originally-presented sort order? Same thing with applying ticks - I'm only going to attempt to recover items with State of 'Excellent', and maybe size > 1KB or 2KB depending on the doc type. Trying to get a handle on the general state of things when working with a list of >1million items is inevitably time-consuming. Maybe it is unrealistic to get it done in one session. It might be handy to be able to shut down Recuva and resume at a later time without having to run a re-scan of the problem drive. In that scenario a 'save session', 'restore session' option would be of benefit. So, in summary, my suggestions are: 1. Allow more complex filtering to assist those with "disaster recovery" tasks (i.e. whole disc recovery) - State, Size, Date as filter basis 2. (Optionally) allow on-keypress filtering to be suppressed, and trigger filtered by Enter or Go button 3. (Optionally) allow the exported text file to reflect the current filter (ideally, note the current filter details at the head of the export list) - and possibly also the Recover action could be filter-limited 4. Include the "State" assessment in the exported row data. 5. Introduce a "Save Session", "Restore Session" capability to allow recovery work to be attacked in chunks, without having to re-scan what might be a terminal (i.e. almost dead) hard drive. Finally - and feel free to ignore all the above - thanks for this free of charge program which has already done a great job.
  • Create New...

Important Information

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