Two possibilities come to mind: (1) sparse files, and (2) hard links. If you copy in a manner that does not preserve hard links and sparseness, the destination can require a lot more space than does the source. How are you doing the copying?

From within TestDisk. I do the quick scan, then select the partition, then P to copy files. There's no options for the copy, just select and go.

I'm guessing it's a sparseness problem, and I don't see any way to make testdisk preserve sparseness when recovering a file that way. Testing whether those recovered files are potentially sparse (contain long blocks of zeros) is not a simple matter. Restoring the sparseness of a file requires making a copy of it, so you would have to try that on a few files at a time before you have filled all your space.

To make a sparse copy of a file, you can use either cp with the "--sparse=always" option, or rsync with the -S (--sparse) option, e.g.:If the output from "ls" shows that newfile uses significantly fewer disk blocks than does the original file, then you can "mv newfile oldfile" to save the space. If not, just "rm newfile" and proceed to the next.

I know that's a bit painful. A long time ago I did write a C program to test whether a file might be a candidate for being made sparse and make a sparse copy if so, but it's dependent on specific filesystem features and I'm not sure it even works any more.

Thanks everyone who tried to help. I'm going to mark this thread as solved. I don't think I can go any further with retrieving anything from this disk.