cgsecurity.org

Hi there and thanks a lot mr.Grenier for such a mighty toolset that had helped me many times so far!

1) How I got into a problem: I have a portable USB HDD (1Tb advertised / 931Gb factual volume), "WD My Passport Ultra" factory-formatted in NTFS (one big partition), used for backup of pretty much anythng.
I was running official Windows 10 Install Media Creation tool, and 2 USB devices was meanwhile connected to my laptop: 16Gb USB flash-drive (intended to made it Win10 installation media), and the named WD HDD, I was copying various files there.
Eventually Windows Media Creation tool did some USB trick (I guess it forcibly dismounts the flash drive before formatting it), and for some reason it formatted the wrong device.
So now I have the 1TB HDD, whose first 16G are partitioned as Windows10-compatible EFI bootable drive, + its first 4Gb overwritten with Windows installation data.

2) I could not make TestDisk find anything that resembles my initial 931Gb partition, so I resorted to PhotoRec. In fact, the most valuable files there was the photos, so I am ok with that.

3) (Actual difficulty). Among other files, there has been several (well, at least one) ISO images of some Linux distro(s) written there.
I ran Photorec overnight, it indeed recovered many photos, video files, PDFs, etc. But at some point it apparently slowed down significantly (elapsed time 17h, estimated time to completion 34h and steadily increasing). What's worse, looking at the files being recovered, it looks like it is now producing a huge lot of duplicate files. It is hard to make strict comparison, but here what I see:
- I take 100 directories ( recup_dir.1000 .. recup_dir.1099 ), re-sort them to obtain files by ext:
(*.elf, *.pyc, *.deb, *.sh, *.tz, *.sqlite ) ~= 13000 files
*.xml ~= 13000 files
*.txt ~= 7500 files
*.gz ~= 4200 files
*.html ~= 11500 files
*.gif ~= 300 files
-- and there's no files w.different filetypes there

the next 100 directories sum up to the same list (numbers changed slightly, about +/- 1 per cent ), and the next 100 dirs are the same, and now it is getting up to recup_dir.36xx - all the same files there. They all look related to some distro (*.gz being man pages, html+gif = some documentation, XMLs are Docbooks, Maven files etc ).
That is, looks like Photorec stepped into some ISO file(s) and cannot get out of it (additionally, taking up extra space to store duplicates).

4) My questions are:
-- Have anyone encountered such a behavior?
-- Is this process finite?
-- Is there any way for me to help Photorec, e.g. to ask it "step over" some problematic range?

Thank you in advance, and, one more time, many thanks the author!

Unless you store the recovered files on the source partition, PhotoRec should not recover the same files again and again.
Do you have the problem with latest 7.1-WIP ?

Yes, the latest release, freshly downloaded 7.1-WIP. I ran it on Win10.

I understand that my description is based on a totally wild guess, not too much I can investigate here, sorry for that. Probably this has nothing to do with ISO files, maybe some different linux-specific quirk manifest itself this way. All I see, a huge number of gz-manpages, elf executables, OpenSSL docs, etc.

Meanwhile I found the way I can recover from parts of disk image, instead of full disk. Now I am doing "dd" to sequentially obtain 50Gib chunks of disk and using PhotoRec on these chunks. This way, I hope to circumvent the problematic disk area, so far it is going well.

(Sorry, forgot to mention)

At the moment I stopped it, the sector progress counter was running upward steadily, not returning back, though "estimated time" was also increasing fast.
When estimated time went up to 40 hours, I just aborted it.

Probably, I should had just waited until it left the problematic range, and continued normally.