cgsecurity.org

Posted: **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, 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.

Posted: **06 Jul 2020, 22:43**

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.

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.

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.

Posted: **07 Jul 2020, 17:13**

I will re-order your post, to reply more naturally (to me, at least)

recuperation wrote: 06 Jul 2020, 22:43 Recovery is always time consuming but you are not required to watch Photorec when it's working.

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.
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.

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.

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.
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

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.

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 (it's not straightforward as

Code: Select all

strings | grep

or just

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.

Posted: **07 Jul 2020, 18:48**

rhiannapfeffer29 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

"unnecessary IOPS" => buy a faster CPU
"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.

Posted: **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 ...

recuperation wrote: 07 Jul 2020, 18:48 "And the risk of running out of space" =< buy RAM and bigger harddrives

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 ...
I might as well have invested in a mirrored backup to begin with

recuperation wrote: 07 Jul 2020, 18:48 The implementation of a new file format in code or as fingerprint => PRICELESS!

... true. My hat's off to the person that created the 7z and the jpg signatures.
But I am not sure where does that fit into my post.

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.

Unfortunately, the article won't help me, as I cannot read German.
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?

Posted: **06 Sep 2020, 16:42**

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.

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.

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 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).

Posted: **10 Sep 2020, 12:23**

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 ...

Thanks for the hint, I thought this were CPU cycles!
Photorec is programmed in C. There is little margin for optimization, if any.
I do not see any importance of this feature request.

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 ...

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.
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.

cgsecurity.org

Photorec Further Filtering

Photorec Further Filtering

Re: Photorec Further Filtering

Re: Photorec Further Filtering

Re: Photorec Further Filtering

Re: Photorec Further Filtering

Re: Photorec Further Filtering

Re: Photorec Further Filtering