Hello there,
I was wondering if Photorec provides a more fine-tuned approach to data recovery - for example, filter by string/regex, and approximate size.
I want to recover jpg pictures with specific EXIF data (model, date), that, because Windows, those files were `chkdsk`d and "found" the files to be 0 byte.
I assume that means that I have to search the entire drive. However, in doing so, I don't want to recover / re-create existing images and/or spend time recovering unnecessary data.
Photorec Further Filtering
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
-
- Posts: 3
- Joined: 06 Jul 2020, 21:58
Photorec Further Filtering
Last edited by rhiannapfeffer29 on 07 Jul 2020, 16:40, edited 1 time in total.
-
- Posts: 2729
- Joined: 04 Jan 2019, 09:48
- Location: Hannover, Deutschland (Germany, Allemagne)
Re: Photorec Further Filtering
The answer ist no.rhiannapfeffer29 wrote: ↑06 Jul 2020, 22:08 Hello there,
I was wondering if Photorec provides a more fine-tuned approach to data recovery - for example, filter by string/regex, and approximate size.
I want to recover jpg pictures with specific EXIF data (model, date), that because Windows were `chkdsk`d and "found" to be 0 byte.
I assume that means that I have to search the entire drive. However, in doing so, I don't want to recover / re-create existing images and/or spend time recovering unnecessary data.
If you want to filter recovered images based on approximate size you have to recover the image first to determine the picture size. After finishing you can decided if it fits your target size. Unfortunately the recovery time is lost even when you decide not to keep the picture.
How should any recovery program know in hindsight that it might "re-create existing images"?
Again, the time is spent, the result is not desired by you but the time is lost anyway.
Recovery is always time consuming but you are not required to watch Photorec when it's working.
Parts of your text is not comprehensible for me. Cleaning my windows with glass cleaner was always sufficient in my life. I have no idea how I should checkdisk them.
There is no reason to reinvent the wheel when other software can do that pure selection you intend to do.
-
- Posts: 3
- Joined: 06 Jul 2020, 21:58
Re: Photorec Further Filtering
I will re-order your post, to reply more naturally (to me, at least)
For the non-trivial "deleted-my-file-from-the-recycle-bin-1-minute-ago" case, it usually means you should start it and go to sleep.
In hindsight, it appears that other users even in this forum have faced:
viewtopic.php?f=5&t=10251&p=31340&hilit=chkdsk#p31340
viewtopic.php?f=7&t=10130
The unnecessary IOPS
The lack of flexibility
And the risk of running out of space
I can see why it is easier to just "recover everything and worry later".
However, given that my target is Windows and I have Un*x background, I find it complicated to "filter later" - or "filter" for that matter (it's not straightforward as or just )
Additionally, I usually take a lot of shots with refining my target - and now in ways that are incompatible with photorec (e.g. I am searching for jpg, and then the "what if I can also find ISOs" moment)
I understand that photorec is a year's old software, and I won't "just change it".
I merely wanted to bounce off ideas, so that I educate myself more with it.
That is true, yes. I think usually file recovery tools go like that: Drive should be mounted RO, and let the recovery program do its work.recuperation wrote: ↑06 Jul 2020, 22:43 Recovery is always time consuming but you are not required to watch Photorec when it's working.
For the non-trivial "deleted-my-file-from-the-recycle-bin-1-minute-ago" case, it usually means you should start it and go to sleep.
I really should avoid posting at nights. I think I was hit by a Windows/Microsoft bug and I felt I had to rant about Microsoft. Apologies.recuperation wrote: ↑06 Jul 2020, 22:43 Parts of your text is not comprehensible for me. Cleaning my windows with glass cleaner was always sufficient in my life. I have no idea how I should checkdisk them.
In hindsight, it appears that other users even in this forum have faced:
viewtopic.php?f=5&t=10251&p=31340&hilit=chkdsk#p31340
viewtopic.php?f=7&t=10130
Given all of the above: Overall, I am more concerned (take it with a grain of salt) for:recuperation wrote: ↑06 Jul 2020, 22:43 The answer ist no.
If you want to filter recovered images based on approximate size you have to recover the image first to determine the picture size. After finishing you can decided if it fits your target size. Unfortunately the recovery time is lost even when you decide not to keep the picture.
How should any recovery program know in hindsight that it might "re-create existing images"?
Again, the time is spent, the result is not desired by you but the time is lost anyway.
There is no reason to reinvent the wheel when other software can do that pure selection you intend to do.
The unnecessary IOPS
The lack of flexibility
And the risk of running out of space
I can see why it is easier to just "recover everything and worry later".
However, given that my target is Windows and I have Un*x background, I find it complicated to "filter later" - or "filter" for that matter (it's not straightforward as
Code: Select all
strings | grep
Code: Select all
grep
Additionally, I usually take a lot of shots with refining my target - and now in ways that are incompatible with photorec (e.g. I am searching for jpg, and then the "what if I can also find ISOs" moment)
I understand that photorec is a year's old software, and I won't "just change it".
I merely wanted to bounce off ideas, so that I educate myself more with it.
-
- Posts: 2729
- Joined: 04 Jan 2019, 09:48
- Location: Hannover, Deutschland (Germany, Allemagne)
Re: Photorec Further Filtering
"unnecessary IOPS" => buy a faster CPUrhiannapfeffer29 wrote: ↑07 Jul 2020, 17:13 Given all of the above: Overall, I am more concerned (take it with a grain of salt) for:
The unnecessary IOPS
The lack of flexibility
And the risk of running out of space
I can see why it is easier to just "recover everything and worry later".
However, given that my target is Windows and I have Un*x background, I find it complicated to "filter later" - or "filter" for that matter
"And the risk of running out of space" =< buy RAM and bigger harddrives
The implementation of a new file format in code or as fingerprint => PRICELESS!
Unix philosophy is about doing one defined task well as I had to learn.
Testdisk is the most comprehensive swiss tool for partition repairs on devices.
Photorec is the most powerful for fingerprinting recovery:
Buy the article: https://shop.heise.de/katalog/jager-der ... ten-8a0fb1
These features distinguish Testdisk and Photorec from their competitors.
There is no reason to have both do a little bit of everything like their commercial competitors.
Furthermore recovering data is not a fast process that is suitable for a Unix chain of commands.
-
- Posts: 3
- Joined: 06 Jul 2020, 21:58
Re: Photorec Further Filtering
IOPS is a storage feature, not a CPU one ...
If I have "already" big harddrives, then I need... "big-big" harddrives.recuperation wrote: ↑07 Jul 2020, 18:48 "And the risk of running out of space" =< buy RAM and bigger harddrives
A (rather arbitrary) rule would be that I need 0.5-1 times the size of the HDDs I am recovering ...
I might as well have invested in a mirrored backup to begin with
... true. My hat's off to the person that created the 7z and the jpg signatures.recuperation wrote: ↑07 Jul 2020, 18:48 The implementation of a new file format in code or as fingerprint => PRICELESS!
But I am not sure where does that fit into my post.
Unfortunately, the article won't help me, as I cannot read German.recuperation wrote: ↑07 Jul 2020, 18:48 Unix philosophy is about doing one defined task well as I had to learn.
Testdisk is the most comprehensive swiss tool for partition repairs on devices.
Photorec is the most powerful for fingerprinting recovery:
Buy the article: https://shop.heise.de/katalog/jager-der ... ten-8a0fb1
These features distinguish Testdisk and Photorec from their competitors.
There is no reason to have both do a little bit of everything like their commercial competitors.
Furthermore recovering data is not a fast process that is suitable for a Unix chain of commands.
That is true. Additionally, being able to separate Search and Recovery does not strike me as something necessarily bad.
In the true forensic / every spin of the HDD might be its last scenarios, you may want to just get out as much as possible as fast as possible.
Are there no other directly supported scenarions?
Do they contradict with the prime directive of the program?
-
- Posts: 50
- Joined: 07 Jun 2020, 20:38
- Location: France
Re: Photorec Further Filtering
Indeed, and in this case doing an analysis first to identify files based on certain characteristics, then going back to actually extract them if the requirements are met, would be inefficient from that point of view, and would take longer than extracting everything on-the-fly. That said, data recovery on a failing storage device should always be performed on a clone / image, rather than directly from an unreliable device.In the true forensic / every spin of the HDD might be its last scenarios, you may want to just get out as much as possible as fast as possible.
In this situation, filesystem based recovery is usually much more efficient, if the file allocation information is still present -- quicker and more reliable as you get the complete file even if it is fragmented, along with its timestamps and other attributes ; with “raw” recovery by means of file signature search, you only get the file's contents, if luckily it wasn't fragmented, it can do wonders in disaster situations where the filesystem is badly damaged, but it is not the first / best option in such straightforward situations. With a freewre like Recuva it takes seconds to analyse the partition. A file which was lost because of a CHKDSK SNAFU, on the other hand, is a situation where Photorec might succeed while a filesystem based analysis might not (because the original filesystem metadata for that particular file was most likely lost).For the non-trivial "deleted-my-file-from-the-recycle-bin-1-minute-ago" case, it usually means you should start it and go to sleep.
-
- Posts: 2729
- Joined: 04 Jan 2019, 09:48
- Location: Hannover, Deutschland (Germany, Allemagne)
Re: Photorec Further Filtering
Thanks for the hint, I thought this were CPU cycles!rhiannapfeffer29 wrote: ↑07 Jul 2020, 19:44 recuperation wrote: ↑
07 Jul 2020, 18:48
"unnecessary IOPS" => buy a faster CPU
IOPS is a storage feature, not a CPU one ...
Photorec is programmed in C. There is little margin for optimization, if any.
I do not see any importance of this feature request.
I already smelt a rat. You are not the first one who "must" repair his drive because he has no free space for recovered files.rhiannapfeffer29 wrote: ↑07 Jul 2020, 19:44 If I have "already" big harddrives, then I need... "big-big" harddrives.
A (rather arbitrary) rule would be that I need 0.5-1 times the size of the HDDs I am recovering ...
You don't need very big hard drives. In linux you can use LVM to combine physical drives into a bigger logical one - but until now I never had to use that feature.