Hi,
Just for the context: recovering both from USB disks and image files. In x86_64 GNU/Linux.
Sometimes, photorec just stays. Not frozen, you can even see disk activity. It just stays. The Reading sector remains the same, Elapsed time and Estimated time to completion remain the same, too. You can't quit only kill.
After a while, sometimes after a long wait, it moves on. BTW, if you tried to quit this is the moment when the quit command is considered. The reading sector and the times jump/increment.
First time I thought it is recovering a big file but I'm not sure anymore. Do you know what really happens during this "stay"?
Sometimes, photorec loops. The reading sector increments to a (not) certain value then drops to a lower one. Usually the result is a file per loop.
First time I thought it is recovering a fragmented file but I'm not sure anymore. Do you know what really happens during this "loop"?
I both cases I note the reading sector (where it stays or, respectively, from where it falls back) round it up to an 128-multiple (as, probably incorrectly, understood from an older, locked post) and put this value in photorec.ses after closing/killing the process.
Then restart photorec_static. Probably some files are lost but at leas the things are moving on.
Do you have a better way of dealing with these cases?
Thank you,
Vane
Loops and pauses
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
-
recuperation
- Posts: 3036
- Joined: 04 Jan 2019, 09:48
- Location: Hannover, Deutschland (Germany, Allemagne)
Re: Loops and pauses
Which version do you use?
Do not enable brute force.
I only know the general working principle of Photorec. I don't know what causes a loop situation.
Unfortunately you have to be patient or use a third party software.
Sorry, I can't explain your observed behaviour!
Do not enable brute force.
I only know the general working principle of Photorec. I don't know what causes a loop situation.
Unfortunately you have to be patient or use a third party software.
Sorry, I can't explain your observed behaviour!
Re: Loops and pauses
I am using PhotoRec 7.2-WIP, Data Recovery Utility, Novembre 2020.
Thank you for the answer, maybe somebody else knows more.
Waiting patiently, here, too!
Thank you for the answer, maybe somebody else knows more.
Waiting patiently, here, too!
-
cgrenier
- Site Admin
- Posts: 5441
- Joined: 18 Feb 2012, 15:08
- Location: Le Perreux Sur Marne, France
- Contact:
Re: Loops and pauses
When a file is found, if a file was fragmented in the previous 200MB (restricted to 3 sector ranges), PhotoRec will try again to recover the file.
There should be no pause unless there are bad sectors: areas where bad sectors are present take a very long time to read.
There should be no pause unless there are bad sectors: areas where bad sectors are present take a very long time to read.
Re: Loops and pauses
Happy Holly days!
I am sure there is not a single bad sector. My data loss occurred due to a Microsoft Storage Space Failure not due to a disk error.
The recovery process is 92.50% terminated. In approximately 2:59:40 it will be finished (calculated in Excel not based on PhotoRec estimation)
Then I''ll run a deep surface analysis to confirm the "no bads" statement and come back here.
see you.
I am sure there is not a single bad sector. My data loss occurred due to a Microsoft Storage Space Failure not due to a disk error.
The recovery process is 92.50% terminated. In approximately 2:59:40 it will be finished (calculated in Excel not based on PhotoRec estimation)
Then I''ll run a deep surface analysis to confirm the "no bads" statement and come back here.
see you.