cgsecurity.org

I'm trying to recover some recent "docx" files (related to a period of time after begining of this year) saved on an 1TB HDD that seems having some problem, maybe related to filesystem corruption or possibly at hardware level too. The partition of interest contains about 300 GB of data.

I don't have enough free space on my drives to execute a proper imagining of the disk (like using ddrescue or similar tool). So I tried the risky way of rescue directly from the source HDD to a folder of my 500 GB SSD, there is just one partition on it.

Photorec found several DOCX (zip family) files but after many many hours of work it stopped and returned the following Warning: My current directory, where I chose to store rescued files is on an EXT4 filesystem, while the source partition is on NTFS. I'm running photorec from shell on a slackware linux system. Here "df -h" command output:
As you can see it has just 36% of used space.
So why Photorec complains about not enough available space?

As I said, anyway I found many DOCX files in the store directory. Also related to the period I was looking for...
But this warning make me suspicious: I would not leave some files behind, if possible.

Any suggest?

You have been severly punished for not having duplicated the disk in question and not using a different file system as target!

I can only guess that you ran out of i-nodes. An i-node in ext4 is the equivalent to a MFT (master file table) entry in NTFS with the delicate difference that NTFS can grow and shrink its MFT table as needed.

As for as I know, the number of i-nodes is fixed in ext4.

Check google to see how to find out the degree of i-node utilization!

The best solution is still to get another free disk, partition it for just one partition and format the disk using NTFS!

One annoying and time-consuming solution I guess is to make a little bit of space by moving rescued files somewhere else. These files do not need to be long, it is only about freeing i-nodes!
Next thing would be to calculate how many finished recup-folders fit into the free space. You would then create one zip archive containing as many recup-folders as fit space-wise into your free space. Do not use compression, you are dealing with already compressed zip files.

Once the creation of the zip file has terminated you should delete the recup-folders that you duplicated into the zip archive. This would free i-nodes on your ext4 partition/volume. The number of i-nodes freed would be the sum of all folders and files in your zip archive.

The disadvantage here is that your are copying internally on one disk. This creates head movements and slows down the process.

There might be a faster solution but I don't know if it works and if its fails it would put your whole SSD at risk.