Augeas

OK, that theory's out then.

What exactly do you mean? Is the file live or deleted? What makes you think it doesn't exist?

Lucien (if you're still with us), files that are marked as overwritten are overwritten by a live file, there is no concept of being overwritten by a deleted file. So your hideous images must be live, somewhere on your disk. Recuva will tell you where they are in the Info pane.

There's no auto stop and restart facility with Recuva. If you are running a recovery (which I understand you are) and not an analyse, you could theoretically stop the recovery, identify what the last file recovered was, and then check the files from that point onwards and run a recovery. But if you are dealing with thousands of files this is likely to be quite a headache to attempt. Your recovery appears to be grindingly slow, and Recuva appears to be doing nothing in the Task Manager snapshot.

Simple question first - are you trying to save the files to the same drive? I've only seen this message (can't find file) on files greater than 4 gb, which I can only see one in your list. Apart from that I can't see why you are getting that message for all the files. A file with a header of zeroes is not a valid file, unless it's a text file of zeroes, so it is not a suitable candidate for recovery.

That link is hardly relevant as it discusses correcting an undeleted file, not recovering a deleted file. Recuva does not alter one bit of the data it recovers, or more correctly copies. Carmella, no software can guarantee to recover a deleted file, it depends entirely on the subsequent activity on the disk. If it is an SSD then forget any hopes of recovery. If it did not appear in the list of found files then it's likely that the entry in the MFT has been overwritten. You could try running a deep scan and looking for .doc or .docx files with a size close to the deleted file. If no file exists with the approx size then it is possible that the file is fragmented. If so it is not possible to recover fragmented files from a deep scan with Recuva. Windows updates deleting user files seems very peculiar to me, perhaps someone with more knowledge on this can comment.

No. It's an SSD and on formatting a global TRIM is run resulting in a squeky clean storage device.

What do you mean by unable to recover? Did you find the deleted file? Did you attempt to recover it and failed? Didi you recover it and the contents were not what you expected? How did you delete the file in the first place?

I'm not sure what you mean there. If you plough through http://kcall.co.uk/ssd/index.html it will give me time to go to bed.

That's right, the O/S and the SSD controller will treat the writing of a new file to 'deleted' pages as an update of the pages. By their nature SSDs run with most of their deleted and TRIMed pages unerased, the SSD is shall we say full, even if the O/S only shows live data. Garbage collection is done nowadays i the foreground as it reduces the number of extraneous writes and also lessens the load on portable devices. I don't know how the SSD controller can know that pages are no longer used by the O/S's file system. That info is held in the MFT and cluster bit map which the SSD can't read.

A zero fill would use zeroes from the user's point of view, which is greatly abstracted from the actual values written to flash cells. If the SSD is quite old (10 years +) then it might not support TRIM, in which case a very infrequent WFS might be beneficial. If nothing is done then there is no way for the SSD controller to know which pages have been deleted by the O/S. When a page deleted by the O/S is subsequently reused the SSD's garbage collector will flag that page as invalid and use a previously erased page. You may have to wait a few micro-seconds in this case. This is how USB flash drives work as USB doesn't (or didn't until very recently) support SATA protocol.

I don't use Defraggler so I don't know what options it has but don't you mean CCleaner? Whatever s/w it is the process of writing a file and then deleting it is totally different from erasing a NAND flash block. The SSD's grabage collection routines will erase the (invalid) block irrespective of what has been written there previously. And don't bother to zero or anthing fill an SSD. Windows will not allow you to access TRIMed data, and the block erasure will remove anything that was written before permanently, so a normal delete will do.

There could be several reasons for this. Recuva deep scan runs a normal scan first, so you will see all the deleted file names presented from the MFT. If you have used the 'native' WFS then the file names will be there in their original form. If you have used Drive Wiper then the same number of file names will be there but the names will be in a variable ZZZZ.ZZZ form. In both cases the file data will have gone. You might also have the Show Non-Deleted Files option checked in which case you will see a very large number of live files listed. All these files are 'recoverable', but the wiped ones should return zeroes. If the files found are from the deep scan (their names are [000123].ext or similar) then there are some circumstances where a WFS fails to completely wipe the device. Are the deep scan files all relatively small, say 20k or so or less? I should check the files with names in the Header pane of Recuva to see if they contain zeroes. If so all is fine. You could select all deep scan files and run a single pass secure delete. This will clear those files from the device.

Yes, I would recover files in a bunch at a time, step by step is the way. The original file names will be preserved if they are shown in the scan. For files found with a deep scan, those with a file name of [001234].jpg for instance, file names can't be retrieved.

Unfortunately not. You will have to start again.

Why aren't you trying to scan disk D, which presumably is the 238 gb partition you deleted? Why are you scanning the Recovery partition, which clearly isn't the partition you deleted? Why are you trying to scan a Local Disk, which, whatever it is (someone will tell me) it isn't the deleted partition? The three partitions you describe appear to be on Disk 1, but the partition you apparently deleted appears to be on Disk 0. I am too confused to make any sense of it.

Recuva works by copying data to another drive, creating new files. I know of no practical way of identifying the original dates of the files.

I believe Win 10 disables System Restore by default.

No, the red dotted files have their data overwritten by another file, so they are not recoverable. (Actually they are, but you will be recovering the data from the overwriting file which presumably you don't want.)

Yes, but 96 posts in English, and then this? Are we supposed to get the clown reference? Is it a way of sneaking in offensive language? Was ist der Sinn?

All you can do is sort the file size column by clicking on the column header, and then start from the top.

Or 'Not as far as I know', which is more relative than absolute.

You don't give up, do you? It must be the tolerant attitude we have here.

It means, in the most basic terms, that what you are trying to play is not a video file. What has been recovered will be faithfully what is on the storage device. What is on the storage device is therefore not a playable video file (you can replace video with any type of file). Why is this so? It could be because the file has been overwritten, it's FAT32, it's greater than 4gb, it's an SSD, or it's some kind of coding that needs decoding (I have no idea how Kodak holds its files), or something else I don't know about. Can these files be recovered? There's not enough info (there's not any info) to say yes or no, but one could say probably not.

The file count whilst running includes live as well as deleted files. If you are not seeing any deleted files in the l/h pane then possibly there is some selection criteria entered which does not match any file found. It sounds as if you were running a deep scan which I don't think finds RAW files.