Augeas

What results are you getting? What options are you using?

I would seriously consider using a professional data recovery company. The disk is huge, and using a piece of generalised software on a home machine is going to take days, if not weeks, interspersed with suggestions to run this option or that. Bite the bullet, and backup any results you get.

Not really. The file name will be in a folder somewhere (FAT or NTFS) and it looks as if it's been overwritten or corrupted somehow. The folder path can't be constructed (see the ? in the path) so what's happened to the folder I've no idea. As the file is in one extent you could use a freebie hex editor like HxDen and copy all of the clusters in one go, but that is quite a task. If it's FAT you could use HxDen to rename the file in the directory to something readable and then retry Recuva, if you could find the directory that is. You won't be able to do this with NTFS as the MFT is protected. Or you could - and this is what I would do first as it's easy and non invasive - run a deep scan. I don't think that files that are in folders are recognised by a deep scan but it's worth a try. A deep scan doesn't recognise file names.

Mta, on a HDD you can use whatever character you wish, it will make no difference. As user data is scrambled and coded by the disk controller before being written to the disk there is no way to determine what sequence of ones and zeroes was used on writing nor what it will be on overwriting. So you can overwrite an unknown sequence with another unknown sequence, but you can never actually overwrite a one with a zero, or vice versa, as the scrambling removes the knowledge of whether a one or a zero has been, and is being, written. Overwriting a one with a zero is a logical construct far abstracted from the storage device. On an SSD you can't overwrite anything, you can only write new pages, so the proposition that you can overwrite with zeroes or ones or whatever, no matter how many times, is merely fanciful. To the SSD controller a page is either valid (i.e mapped to a lba and visible to the O/S) or invalid (i.e. not mapped to a lba and not visible to the O/S). This does not represent what the O/S considers to be live or deleted files. File life or death (and fragmentation as well, but that's another long bedtime story) to the O/S is specified in the MFT, or FAT tables. The SSD knows nothing of these. Deleted (TRIMed) SSD pages will be inaccessible to any operating system. Garbage Collection will empty invalid pages by setting all cells to 'ones', and those pages will remain inaccessible until the SSD controller receives a write request and decides to use them. DDR4 ram is volatile, but there are some hybrid cards with ram and non-volatile flash in the pipeline, perhaps this is what is meant. This is a long way from the O/P's suggestion.

I believe that the file system for SD and SDHC cards is FAT32 and the video file format is AVCHD, and the recording is split into discrete elements and stitched together using Canon's software. SDXC cards use ExFat. Canon gives a warning message before formatting that all data will be lost. That's the extent of my Canon knowledge.

These are NTFS system meta files. I wouldn't touch them. Dump the existing files, repartition, reload the files.

You can cancel Stage 2 (or 3) and still see, and recover from, the list of files found.

There's no option to put files back into their (original) folders. You can ask Recuva to restore the folder structure within the folder you're recovering the files to (excuse excruciating grammar). Files with a ? in some part of the path wont have their full folder structure restored as some or all of the folder structure has been destroyed.

Why not, if you have the time. Cancel as soon as it enters stage 2.

Just cancel it. I have never noticed any difference if I cancel stage 2 or 3. You will still get the list of results and can recover any of those files you wish. (I mean cancel within the stage 3 box, not cancel the entire job!)

If you mean their original folders then no. However you can recover to a folder on a separate device and build the folder structure within that folder, and then copy as required back to the original folders. The option to do this is in Advanced mode, Options/Actions, a check box near to the bottom.

As I said, it's unlikely. But as we don't know whether the device was formatted, we don't know exactly what you've done, and we don't know what Eraser does, then we can't say for certain.

The $nnn files are system files set up by NTFS when a device is formatted. It's unlikely that these files will contain any useful data. I don't think that removable devices have shadow copies. It's up to you if you want to reuse or destroy the flash drive. Any Eraser questions should be directed at an Eraser forum.

This is almost unreadable, can't you try a little puctuation? Does this have anything to do with CCleaner? Your third post is quite spammy too.

I think that the OP is referring to the wording, not the actual operation. I agree, zero fill your drive does imply that the entire drive would be wiped. Just zero fill free space would be better, but don't expect anything soon from Piriform. Zero fill is confusing, as the zero-fill concept, much loved by the OCZ community about ten years ago. is pretty much obsolete now with the universal adoption of TRIM. Optimising with a global TRIM gives the impession of running a zero fill, but it ain't really.

I think that plenty of people would notice if the free CC didn't clean. The free version cleans for the current user, where the paid versions can clean for all users.

This is a Piriform forum so specific discussion of competitor software is not allowed. This subject might attract some vitriol as well, so unfortunately the thread will have to be locked.

Yes. Read my previous post.

One post will do, thanks, and I've moved this to Recuva Discuaaion. I presume that your camera cable to pc will result in a drive letter appearing for the card. Just select that drive letter when runnning a scan in Recuva.

Yeah. The Data Factsheet (you know, the stuff nobody reads) states pretty clearly in the first section that: '...it is necessary for some data, such as the operating system you’re on, whether you’re using a free or paid version of CCleaner, and the language you’re using, to be reported.' and '...anonymous usage data doesn’t need to be reported for us to maintain CCleaner, but it does help us to build a better product. It provides us with statistics about what is being used within CCleaner and what isn’t. ... You can choose whether you’d like CCleaner to report anonymous data in CCleaner’s ‘Privacy’ tab.' So you're still going to get that initial ping on CC startup, even if you've unchecked the usage data box. Should you care? That's up to you, I rate it at about the same level as eveyone knowing what make and model of car I use everytime I go to the shops.

After the scan go into Advanced Mode and enter either the file name (or part of it) or the extension in the File Name/Path box.

It's difficult to say with the level of information given, but possibly not. If the image handling software says it's the wrong format, then it's doubtful that the rest of the data holds any image at all. A file name with a .jpg extension does not mean that the file contents are in a .jpg format. You could try a deep scan, and hope that the pics are in one extent.

Click on the column heading for State and the contents will be sorted with Excellent first.

It looks like H can't even access the disk to me. Is that so, or has a scan been run?

Well, just look for it. It's hardly an extensive list, is it? It's easier to wag the slider bar up and down than type something in a search box.