cgsecurity.org

I had a Synology unit where both 2TB drives crapped out (don't ask), and unfortunately the better of the two drives has a damaged partition where the bulk of the user data existed. I've tried other tools to rebuild the partition table but no luck, it just sits as RAW or unidentified. So now I've been trying to recover the data through PhotoRec but here's where I hit my snag...

I'm recovering FROM a 2TB drive TO a 2TB drive and after approximately 1GB of recovery, PhotoRec tells me the destination drive is full. I've verified that the target drive has a proper partition and I've tried formatting it to FAT32, NTFS and ext4, but in each case PhotoRec stops after 1GB. I know the system works properly because I finally gave in and tried mounting a 32GB USB drive which was able to fill to 32GB, but after I dumped it off to another computer and brought it back, the system complained again about a drive being full and then the OS did as well and couldn't re-mount the USB drive... so back to square one, and here to post for help.

I'm not a linux guru but I can figure things out and follow instructions. Can anyone help me with figuring out why PhotoRec gives up when clearly the OS tells me there is 2TB available space on the drive? Any assistance is appreciated, I've searched and read through these forums but the only other topics I found where users had a similar issue either went unanswered or weren't doing the same thing.

Help!
Tx,
Chris

To add to the info above; I'm launching PhotoRec in a PartedMagic environment using a UBCD.

Okay, clearly there is something going on that I can't figure out -- I thought I might try running PhotoRec within Windows, at first I couldn't figure out how to target a drive other than the C: drive (where I had the program downloaded), but then I found this thread:
http://forum.cgsecurity.org/phpBB3/how- ... t1619.html

I put the PhotoRec program on the destination drive and was able to start recovery to the empty 2TB drive. Much to my chagrin, I found that only 20GB of data had been recovered before encountering the same error of "no free space available." Shenanigans! I have 2TB of empty drive space! Okay, 1.8something, but I digress.

Something I tried that may be of interest; I had been recovering into E:\Recovery, I created a different subfolder, E:\Recovery2, and chose that as the destination, and then the process continued but never recovered any other files before telling me there was no free space.

This tool is fantastic when it works, but this unexplained "no free space" error is driving me bonkers!

Seriously guys? Not even a single response? This is driving me insane -- I'm hitting the wall with this software, even though it seems to be the best at doing this kind of work.

The problem may have been due to fseek()
http://git.cgsecurity.org/cgit/testdisk ... 30c4467226
Do you have the problem with latest 7.0-WIP ?
Also avoid FAT filesystem as destination as they don't handle file bigger than 4 GB (sometimes 2 GB).

As noted, I've tried FAT32, NTFS and EXT4 as source drives. I finally narrowed down my filetypes to just JPG and was able to pull off over 60,000 files without it hitting the wall.

Still doesn't explain why it was happening with Windows and a liveboot CD.

@ CapitalC - sorry but I didnt quite catch how you solved the problem you were having?

I've been experiencing the exact same problem for several days ...and it is driving me nuts!

I've been running Photorec (v6.14) off a Gparted live CD and have been trying to recuperate files (just jpgs and docs) to an external HD with a (170GB partition) but after a couple of GBs the program says the disk is full - and asks for a new destination.

I've checked several times to make sure the program had been saving the files onto the correct drive / partition and it had, because it created several "recup" folders but stoped after 20 folders or so?

I am trying to recuperate files from a Linux partition to an external HD (170 GB ex4 file system)

Any help much appreciated!

In some cases, the end of the file is missing, PhotoRec stores data until a new file is found or the end of the disk.
When PhotoRec failed to write more data to the destination file, it deletes the truncated file and asks for a destination with more free space.
It's why if the source disk is 1 TB, you need one TB of free space on the destination even if only half the source disk was used.

@cgrenier - Sorry I dont understand your explanation

Something I noticed though

Somewhere halfway through the operation PhotoRec (or Gparted or my system, Im not sure which) seems to rename the partition it had been saving to, to something else.

For example, say, it had been recovering files to partition SDB1. All the sudden that partition is no longer identified as being SDB1 but it is all the sudden renamed to SDC1 instead. I dont know why or how that happens, but when it does, it ~fails~ to write to the partition that no longer exists.

HOWEVER - when I run partition editor it still shows the partition as being SDB1 (in fact SDC1 does not even show up in the drop down list)

So it is all very confusing to me....

Sometimes a device may reappear with another name (ie /dev/sdb => /dev/sdc and sometimes back to /dev/sdb).
I have seen this problem with disk with bad sectors connected via USB.
A solution is to clone the disk using gnu ddrescue and/or connect the disk via SATA instead.