Feature request: don't save the files option

Using PhotoRec to recover lost data
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
Post Reply
Message
Author
User avatar
obidori
Posts: 3
Joined: 19 Jan 2022, 00:58

Feature request: don't save the files option

#1 Post by obidori »

First of all, many thanks for PhotoRec!

I have the following concern, I am trying to restore files from a very large disc with a broken filesystem. The signature recognition actually works quite well. Unfortunately I have no more space where all the scraped files can go. And I really only need a subset of them. Would it be possible for PhotoRec to do a kind of dry run and only save report.xml? Another option for me would be to set the location of the report.xml separately from the restore location of the files. I have done some small tests and think that I can implement a FUSE file system based on this report and do the rest of the data recovery myself.
recuperation
Posts: 3026
Joined: 04 Jan 2019, 09:48
Location: Hannover, Deutschland (Germany, Allemagne)

Re: Feature request: don't save the files option

#2 Post by recuperation »

STOP the current PhotoRec run before the drive/disk with the recovered files is completely filled up by pressing the <return>-key.
Delete all unwanted files from the recovery location.
Restart PhotoRec. PhotoRec will ask if it should continue with the previous recovery action.

Repeat the above as long as needed.
User avatar
obidori
Posts: 3
Joined: 19 Jan 2022, 00:58

Re: Feature request: don't save the files option

#3 Post by obidori »

Unfortunately, this approach doesn't work for me. Because it's just monstrously time consuming and involves a lot of work that's not well automated. It's not an XY problem.
recuperation
Posts: 3026
Joined: 04 Jan 2019, 09:48
Location: Hannover, Deutschland (Germany, Allemagne)

Re: Feature request: don't save the files option

#4 Post by recuperation »

Your need of a virtual recovery only receiving pointers to the file information is certainly an interesting approach.
But you can achieve your space goal easily in a different way by deleting the recovered files automatically. For somebody who implements file systems on linux this is an easy task to program. Then you are left with the reports and you can implement your virtual file system.

Be aware that the TestDisk package is free and open source. You can modify the source code right to your needs.
User avatar
obidori
Posts: 3
Joined: 19 Jan 2022, 00:58

Re: Feature request: don't save the files option

#5 Post by obidori »

Well I have actually halfway "achieved" my goal by implementing an additional FUSE, that faked all writes unless directories or report files are created. But it's an unsatisfying victory, FUSE is slow, really slow. I guess the whole disk will be read in half a week. Yikes.

You mentioned the open-source approach. I checked GitHub, and someone has already partially implemented what I need. His pull request (82 ) has been sitting there for about five years, waiting to be merged. It looks like he also wanted to build the same thing - a FUSE library to handle report.xml - about seven years ago, but for some reason never finished or published it.

There are two main issues with that PR:
  1. It still saves some files like the JPG previews in t-files
  2. The PR is a few commits behind the current codebase
Now, I’m not a C-guy at all, so getting everything to work properly would be quite a challenge. Another question is whether contributing to this code is even worth it - that PR has been pending for five years, after all.

PS: Eigentlich will ich gar nicht jammern, es liest sich aber trotzdem wie Jammern :)
Post Reply