Augeas

Your question is unanswerable. You say 'Can or can't', group CC and Recuva together, and expect an answer of 'Yes or no', which defies any reasoning. The question has not actually been asked in this thread, just the reason why Recuva can't overwrite a file name when CC can, and that has been answered in post 2 onwards. To sum up what the OP stated, CCleaner secure file deletion will overwrite the contents of the MFT file record; Recuva Secure Overwrite will not overwrite the contents of the MFT file record. So if one tried to answer your question it would have been Yes, and No,

Run a normal scan then, in Advanced Mode, either enter all or part of the folder name in the Filename or Path box, or click on the Path column header to sort by folder name. If your folder record in the MFT has been overwritten then the folder name will be, as Nergal says, a ?. Some suibfolders might be found, but otherwise it's back to selecting the individual files.

I love it. A vague question tacked onto the end of an eight-year-old thread discussing long obsolete operating systems. If you're not a spammer, then use Google. If you are, one of us will help you on your way.

I must admit that I am struggling to grasp what is happening, and what is wanted, here. You seem to be somehow confusing Window's shadow copies with Recuva scans. Your first post is especially confusing, what's the connection between the first and second paragraph? A terminated Recuva scan is not a failed shadow copy. And in post 3, 'The time difference between the first and last shadow copies in each of the two groups indicate that the first shadow copy in the group is not a full shadow copy. It was either a error flagged by Recuva or me terminating the scan.' How is a Recuva cancelled scan affecting a Windows system operation? If - in the end - you want Recuva to indicate whether the system shadow copies are good or bad then (whilst that might theoretically be possible) I think that the chances of that are slimmer than Alonso becoming F1 world champion. You don't have to delete the failed copies, just let them cycle round. If you want to rerun those that have failed then that is another matter.

Your problem might be in 'enabled almost everything'. If you checked Scan for Non-Deleted Files then that's what you will get, all your live files as well as those deleted. Among the live files will be a set of system files beginning with $, including $BadClus. These system files are not normally deleted, and although they can be recovered (in as much as a copy can be written elsewhere), they can't be used for any recovery purposes. I think that $BadClus is a sparse file, which means that on recovery it will attempt to recover the expanded size, which is all the disk space. I should cancel the recovery. Still with the existing scan, uncheck Scan for Non-Del etc. There should now be many tens or hundreds of thousands of files fewer to recover. Now run your recovery on what's left.

The next step is to decide whether you have a Nikon camera (as in this thread) or a Samsung phone (as in the other thread you tagged onto). Both have entirely different O/S's. Perhaps you could start your own thread.

Just use one pass, the other options are a waste of time.

It appears to be some context type handling incompatibility, there's lots about it on Google, mostly way above my head.

I know nothing about Edge, but this file looks like an Edge system file, so my guess is that it isn't deleted when it's cleared, just the contents wiped. So looking for a deleted copy might be fruitless. Perhaps an Edge user can comment. But you could still search for it whilst waiting. I also guess that you use your pc extensively for your living, such use will further reduce the chance of any deleted file recovery. 1) Users is OK (I believe, I don't run Win10) 2) Yes 3) A deep scan will not return the file name or path, so there's no advantage at this stage to run it. Run a normal scan with no search criteria specified, then enter filters afterwards. A normal scan will always scan all of the MFT so the run time is the same.

Your card is almost certainly formatted as FAT32, and there are some aspects of deleted files that make recovery of an intact file quite difficult. In a file's directory entry there is a field holding the address of the file's first cluster. In the FAT there is a chain of cluster addresses linked off this first address, all the way to 0xFFFFFFFF for the last entry. When a file is deleted all the entries in the FAT are set to zero. This is the only way that FAT can tell if a cluster is in use or not. When the card has had some use the chances of the clusters being contiguous, especially on a large file, reduce. As the cluster addresses of deleted files have been zeroed, it is not possible to retrieve more than the first extent of a fragmented file. The first cluster address is still held in the directory, so Recuva will retrieve that and all following clusters until a non-zero FAT entry is reached, or EOF as indicated in the directory. Your failure to play the recovered movies may be that they are truncated, Does the file size look OK, or less than you expected? FAT32 may also corrupt the first cluster address, depending on how Nikon have implemented it, which makes it even worse.

When I follow your link I get an immediate 'Do you want to run/save?' message with the correct filename (rcsetup153.exe). If you go to the bottom of your link page there is a link to the builds page, where you can choose the standard install or the portable version. It doesn't matter whether you use this or your link to get the installer. I don't know where your file came from, it certainly isn't any of Piriform's software. I should dump it and download again.

It would have been quicker than getting someone else to do it for you - download the required file from http://www.piriform.com/recuva/builds instead of wherever your file came from.

I think we're a long way from Recuva's interpretation of a file's status. Perhaps you'd be better advised on a Seagate software forum.

The state of Unrecoverable means that all the deleted clusters have been subsequently overwritten; Very Poor means that most have; Poor means that some have; and Excellent means that none have. No software can tell you whether the contents are what you want. I would say that not having a preview (on those file types that should have a preview) is a good indication that the file is damaged. The file systems on a hard drive and a flash drive are different, and how files are deleted and recovered is very different. 'Despite this drive also not even being plugged in, I got full previews with both programs too. This was really impressive,' - that is impressive indeed. I don't quite get the gist of what you're trying to say. I don't know whether you have your files or not, or why your data on a good drive is inaccessible.

In Recuva List view, click on Path at the top of the second column. All of the columns can be sorted in this way, but only one at a time. If you're in Tree view then the file list is already sorted by folder. And in case you ask, a ? means that the path can't be determined.

Right click inside the results pane and select View Mode/Tree View. This will show the scan results by folder. In Options/Actions check the Restore Folder Structure box. This will recover the folder structure (within the folder containing the recovered files). Sort on folders by clicking the Path column header. The Filename/Path will select by file extension. Pics etc without the correct file extension will not be selected. Other questions: Yes, sort on State by clicking the column header No, a recovery creates new files No

Your card is most likely FAT32 and when a file is deleted the first character of the file name is altered to x'E5' which is non-displayable, and the first two bytes of the file address are set to zero, Regarding the latter Recuva is probably looking in the wrong place for the files. That also explains the unrecoverable message. A deep scan might help.

I guess it depends on how much of the 1tb disk is free space. WFS is, I assume, a more intensive process than a low-level format. Firstly (if Drive Wiper is used, or Wipe MFT checked) CC requests the file system to create enough small files to fill the MFT then to delete them. There may be tens or hundreds of thousands of files created and deleted. The actual free space wiping requires a similar process - Fill the disk with files until it is full then delete them. It's an easy process to describe but there's a huge amount of work for the file system.

It depends on how the file was deleted. If it went to the recycler first then it would have been renamed to $Rnnnnn.txt. If a shift/del then sometimes deleted files can be overwritten, and this is most likely with recently created/deleted files (due to the way MFT entries are reused). Your eight-year old file must have existed at some time on the drive. The ? in the path name signifies that there are additional level(s) in the path name that can't be reconstructed. The # folder name is not significant, apart from being an unnecessary sidetrack to the problem.

CCleaner.

1) Personally I would run the scan without any restrictions. A scan will always scan every file/cluster so no time is saved in specifying any file type, in fact running multiple scans is very time wasting. In Advanced mode you can select and unselect whatever file type you like from the original scan. 2) Recuva does not overwrite any file no matter how many times you scan. Other operations on your pc might, but Recuva doesn't. Don't recover to the same partition. 2 and a bit) I always run in Advanced mode, I believe it gives more control. The scan results should be identical, but in Advanced mode you can see what you're doing. 3) You can sort on State by clicking the column header. Excellent (green) will be at the top. You can then do a mass recovery and sort the results later.

From Recuva? For normal deletions I don't think so. If you use CC's secure file deletion then I think that the last modified time is the deletion time.

Very difficult to say without knowing exactly what you are doing - i.e. sitting in front of your pc.

It's quite possible. Recuva looks for entries in the MFT for deleted files: some of those files may well have been allocated space previously allocated to another file, so two deleted files will have the same clusters allocated to them. Recuva will then attempt to recover the same clusters twice - or even more. On a 2tb disk this is horribly more complex than that explanation. Did you run a normal or deep scan? Did you check Scan for Non-Deleted Files? Did you chose to recover everything? You could select only files in an Excellent state and exclude all files beginning with $ to reduce the size of the restore.

These are recoveries of separate files which have the same name, either in different directories or the same file created and deleted many times (isn't .eml an email file?). Recover adds the numbered suffix to avoid name conflicts. You could try to merge them but I don't think that there's any chance of success.