cgsecurity.org

I am trying to use Photorec to recover files from a failing 250 GB NTFS-formated Lacie hdd. The hdd has a bunch of bad sectors so I made an image of it with ddrescue and managed to save everything except 94 kB. I tried to use TestDisk to recover the filesystem but it seems to have been lost. So, I started running Photorec on the image with default settings and things seemed to be working fine. The files were ticking in and the estimated time of completion seemed reasonable. But after having gone through approximately 218,000,000 of the 488392002 sectors and discovered 25,000+ files it got stuck in a frustrating behavior.

The sector number will scan up to approximately 218,630,000. Then it freezes for a while (during the freeze there is no activity from the second hdd which holds the image, but instead the Photorec process consumes all the cpu speed). Then the sector number jumps to a higher number, the number of files found increases by one and the sector number goes back down to approximately 217,170,000 and starts scanning up again. This pattern repeats itself over and over again. Each cycle takes approximately 3.5 minutes and only one new file is found each time. This has now been going on for well over 24 hours. The higher sector number that is only jumped to very briefly after the freeze is slowly increasing and right now it's up to approximately 220,000,000.

From reading the answer to another question in this forum I figured out that the explanation is probably this: After each file Photorec finds it is trying to piece together a large previously found fragment with whatever comes after the newly found file. This means the large file fragment is read over and over again and only a small fraction of the time is spent reading new data. Does this explanation seem reasonable? If so, is it likely that Photorec will ever piece together the fragment and continue normally? Is there any way I can prevent Photorec from behaving like this? Right now, I estimate that it will take 50-100 days to scan the rest of the image in this fashion. I really don't have time to wait that long.

I have written a modified version of PhotoRec to deal with this problem. Can you test it ?
If it's the case, please send me an email with the OS you are using.

Hi, I really appreciate the help, but the problem is already solved for my part. After a couple of days Photorec finally moved on and scanned the rest of the hdd in normal fashion. It actually got stuck in a similar way at least once more, but it only lasted a couple of hours that time.

I still have the image left, so I could test if the modified version works better, if it would help the development of Photorec, but it would not be of any use to me. Do you want me to do this? If so, I have mac os 10.6.7.

I have uploaded a new 6.14-WIP version. Can you test it ?

Hello and sorry for resurrecting this old thread.

I'm currently having the same issue however over a large area (300gb), without the file recovery counter increasing and with crashes after a day or so when using E01 format (now I've converted the disk image to RAW and the crashing seems to have stopped). I've tried both latest stable version (6.1.4) and WIP but they both seem to exhibit this issue however 6.1.4 reports more images recovered before getting stuck (unless 7.0 has better integrity check on images therefore less broken images being extracted).

PhotoRec 7.0-WIP has stricter check than previous version for a lot of file formats.
If the program crashes, please paste the ouput of "photorec --version" and the debugging information displayed when it crashes.

Unfortunately when the crash is related to the use of the E01 format I get no messages when it crashes, the UI remains shown on screen and I can see the command prompt. I've tried another run with bruteforce on (with the raw DD image instead) and in 5 days the remaining sector count hasn't decreased at all (it was decreasing initially though).

Before running photorec, use "ulimit -c unlimited". This way a core file should be generated when the application crashes.

Hello,
I have a similar problem but my computer can't work for so long due to power problem. I run it for less than 2 hours at a time, and it doesn't hibernate.
Every time I start the system, I resume photorec from the previous section but it generates a new folder containing a report.xml file everytime.
I noticed the size of the xml file is proportional to the time for which the program runs.
I just want to be sure photorec is not restarting the fragment search every time.

I'm using testdisk 7.0 WIP on windows 7 32 bits.

Thanks.

PhotoRec should resume at the last sector.