Feature Request - Display File Currently Being Written

[PacketFiend]

Hi,

One thing I came across running Photorec recently. The disk I was running Photorec on had about 2.5TB of free space at the end of it (never used and so all zeroes), because it was largely unfragmented. Somewhere just before that free space, I assume it found a header matching .tar.gz files. But because the rest of the disk was zeroes, it was attempting to recover a 2.5TB tar file that it would never find the end of.

This mattered because while I had enough storage to recover the 3.5TB of this 6TB disk I knew was used, I didn't have enough storage for all 6TB.

The only way I was able to figure out which file it was currently writing was with some low level Linux system utilities (think like, strace for Linux, dtrace for BSD, or the Windows equivalent would be procmon/filemon). Once I found it, I realized the file it was writing was all zeroes, so, it was a false positive bounded only by the end of the disk. It would have been a LOT easier if Photorec simply had a running display of which file it was currently writing. I would have noticed the same file being written to for an inordinate amount of time.

Adding "[S]kip Current File" would be a nice touch.

[recuperation]

Hi,

One thing I came across running Photorec recently. The disk I was running Photorec on had about 2.5TB of free space at the end of it (never used and so all zeroes), because it was largely unfragmented. Somewhere just before that free space, I assume it found a header matching .tar.gz files. But because the rest of the disk was zeroes, it was attempting to recover a 2.5TB tar file that it would never find the end of.

This mattered because while I had enough storage to recover the 3.5TB of this 6TB disk I knew was used, I didn't have enough storage for all 6TB.

Do not disable file types unless you have a special reason to do so. Finding a valid fingerprint will terminate the recovery of the current file. Be aware that for recovery purposes you need at least a disk that is as big as the recovery source. When dealing with dammaged storage media, twice the amount of space is required. In such a case you should duplicate your disk first.

If you cannot affort buying another disk with a size of 6 TB, use various smaller disks. Under linux I guess you might create files where free space is, make them appear as devices using losetup and assemble all of them using the logical volume manager.

The only way I was able to figure out which file it was currently writing was with some low level Linux system utilities (think like, strace for Linux, dtrace for BSD, or the Windows equivalent would be procmon/filemon).

"von hinten durch die Brust in's Auge geschossen" as the German saying goes. Just look into the recup_dir with the highest numerical value. Sort the content by date. The application of linux rocket science is not necessary.

Once I found it, I realized the file it was writing was all zeroes, so, it was a false positive bounded only by the end of the disk. It would have been a LOT easier if Photorec simply had a running display of which file it was currently writing. I would have noticed the same file being written to for an inordinate amount of time.

Adding "[S]kip Current File" would be a nice touch.

I doubt that this reasoning will convince the author.