couple of basic/noob questions...

Recuva
1

I'm just using Recuva for the first time. I have two super-basic questions that I need answers to before I proceed - I might have more complicated questions as well, but I'll go with the (I hope) easy stuff first:

I have a lot of large files to recover, and I did a first selection of about 100 files, and Recuva seems to have recovered them correctly. Now I want to recover more, so I went back to Recuva and started checking (a lot) more boxes, but then I noticed that my original set was still checked. I certainly don't want to spend the time or disk space to recover them twice - will Recuva realize that it has already recovered them and not do so again? Or do I have to manually go back and find them and uncheck the ones I recovered already? (I humbly suggest that it would be great if Recuva, after recovering files, would mark them visibly as recovered in the file list and uncheck them)

In my first pass I failed to see the "advanced mode" and options, so I recovered files without checking "Restore folder structure" ... OK, no big deal, I can find where 100 files need to go. But I'd like to do the rest of th erecovery process with that box checked, but I see that if I do that, I need to select an option for "Secure overwriting", with no option for "No Overwriting At All Thank You Very Much". I have no idea how the two actions are related, nor why I would have to choose an overwrite method because I've chosen to have files restored to their original folder structure on a new drive. I *especially* don't want Recuva to overwrite the original location of the recovered files - is that what it's going to do? I'm very confused by this and very open to the possibility that I'm just being dense and not understanding what simple phrases mean in my current brain-fried state.

Thanks for any guidance you can provide...

2

Hi mrh, and welcome to the forum.

I'm afraid you will have to uncheck what you have already recovered otherwise they'll be recovered again albeit with a "_1" added to the file name. Recuva won't overwrite the previous version.

Regarding your second question, there isn't as far as I believe any relationship between that check box and the secure file overwriting settings, so you have no need to fear that any overwriting will take place at all.

It is odd to have them grouped together like that and it is a wee bit misleading IMO. To securely overwrite any file you have to check the relevant box/es and then right click the selection and select the overwriting option. Two completely different features.

I'll check with the devs as to why they're grouped together like that. I've used Recuva many times in testing and getting back files and nothing has ever been overwritten.

Hope that helps.

:)

3

Thanks for the quick and helpful reply, Dennis.

I think I can articulate my ideas about how both of those issues could be handled better, but I'll save that for the suggestions forum.

Another question I have, maybe a little more complicated, has to do with the distinction between a deleted and non-deleted file. I'm guessing from the documentation that a file is defined as "deleted" if Recuva believes that the file was placed in the recycle bin and then emptied (or presumably if the file was "permanently deleted" via Shift-Del or other normal manner), and that it is called "non-deleted" (and ignored by default) otherwise. Is that right or am I oversimplifying things?

But the files I'm trying to recover were not deleted by me, and in fact I don't exactly know how they became lost (or orphaned it would seem - so far it looks like Recuva is recovering them all fine, and not ignoring them). I did a couple of unusual things with the hard drive they were stored on, so pretty clearly that's related, but I'm not sure what caused the problem, and I wonder whether figuring that out can help me to use Recuva more effectively and avoiding problems in the future...

I have a WD 3TB "Red/NASware" SATA drive full of media, mostly video, and I am trying to set up a home media server running on ArchLinux. The drive has one big NTFS partition (4096 block size) holding all the files, and has previously only been attached to a Windows 7 PC. In setting up a server I decided to copy all of the media files onto another 3TB drive that is configured to boot into ArchLinux, with one large ext4 partition to hold the media (it is in fact a hybrid GPT/MBR disk, but I think that's not relevant). I removed the drive (by uninstalling within windows and then physically removing it from the external SATA/USB dock), attached it and the destination drive via internal SATA to my linux box, and started a copy job of about half of my files, letting it run overnight. This morning I saw that the job was finished but there was an error message on 3 or 4 files saying basically "file not found", which seemed odd since all I had done was to type "cp -p /source /destination". The files on the destination drive looked fine, though those few files were missing, and the size of the directory was considerably smaller than expected (maybe 700G instead of 1T). I could tell what some of the missing files were, so I looked at the source drive and sure enough, they were missing there as well. I brought the drive back to Windows and started using Recuva.

My first question related to Recuva (or maybe other recovery software) is whether it might be possible to just recover the files in place, without moving them, in a non- or minimally-destructive way. It seems like all the files' data is still there, they've just become orphaned somehow. I realize there's always some risk that in restoring the directory data for one file you might overwrite some content data for another, but I would be willing to take that risk since they're not mission critical files. If I choose to recover to the same disk in Recuva, will it leave the contents of the lost files in their current locations, with a "best effort" to not overwrite anything else important? Or is there some other method of restoring the directory connections without stepping on anything else?

My second question is perhaps better asked somewhere else, but I'm sort of on a roll I guess. Any idea what is likely to have caused my problem? I have always believed my method of removing the drive from Windows (uninstall through device manager, power down the dock, remove the drive) to be safe, and my ArchLinux box seemed perfectly capable and happy to be dealing with a >2TB drive. What I did with it connected to Linux was minimal - I looked at the disk partitions to make sure Linux was seeing them, and then I ran copy/cp *from* that drive to the other drive.

In poking around I'm seeing some indication that just connecting it to internal SATA might have been a bad idea - something about motherboards seeing it as 512 block size in order to consider it as a boot drive, but I wasn't using it as a boot drive. Anyway, at the moment this seems like th amost promising clue.

If anyone has any helpful knowledge on this, fire it at me...

Thanks again for taking the time to help out (especially if you've actually read all the way to the bottom of this epic)...

4

In both NTFS and (a normal scan) in Recuva a file is classed as deleted if the entry for it in the MFT has the record in use flag set to zero. Explorer or File Manager, whatever it's called, will never see these files. Non-Deleted are all those files that Explorer can see. Files in the Recycler are not deleted until tne recycler is emptied.

No, there is no recover in place option, either in NTFS or Recuva. If you recover files to the same device then NTFS will simply do what it does when it creates a new file, i.e. use the first available free record in the MFT and assign the data cluster according to its find free space algorithm. It does not know or care what was there before.

As for your other questions either I don't know or it's too far past my bedtime. Actually it's more likely the former.

5

Thanks a lot for that - I'll keep shifting files around on other drives to recover my files elsewhere then.

On one Recuva pass it reported 123 fully recovered and 1 partially recovered file, but I can't see how to tell which file was partial. I'm probably being blind, but if someone could let me know I'd be grateful (sorry if it's in a help file somewhere - I searched, I swear).

6

Unless you made a note of the file name in the info box after Recuva ran, then I don't know of a way to identify that file, apart from opening all the files in order until you hit it. There might be some file checking software somewhere, but I've never had the occasion or desire to look for it.

7

Thanks for the reply! It's great to get such good responses on this forum.

I figured out a way to find the file - set Recuva back to List view instead of "Tree", sorted by "State", and scrolled down until I found the "Poor" section, and just looked for the file with the box checked. Obv this only works if you haven't "overwritten" your check-marks (see what I did there?) with another scan, and if you used check-marks in the first place instead of selection.

I can actually easily imagine this being a major problem, if a first-time (or just inattentive) user does a massive scan, gets 1000 fully recovered files and 150 partially recovered, neglects to write down the 150 filenames (which would be a big pain anyway), ending up with 1150 files and not knowing which ones are corrupt.

It seems like having an option to get Recuva to write a log file would solve this and other problems. If a user ... lets call him me ... were running several recovery scans and recovering files to several different hard drives because he doesn't have a terabyte free in one place, he/I wouldn't have to clumsily look through and make sure he's getting all the files and not recovering any big files twice (which he/I have done 3 tomes so far). And if he (me again) on his first couple of scans didn't notice that there was a "Maintain folder structure" option, at least he could refer to the log file and see what directory Recuva thinks the file came from.

Don't get me wrong ... I might be moderately frustrated with some of the UI design choices, but my level of gratitude & relief at having almost all of my files recovered perfectly outweighs my frustration by three or four orders of magnitude.

thanks again