Augeas

The numbered files ([001234].odt for example) are first extents of a file found by a deep scan. The named files are found by reading the MFT and should return all extents of a file, unless those extents have subsequently been overwritten. A deep scan can only identify the first extent of a file by reading the file header. Subsequent extents don't have a file header so cannot be identified as such and are not returned by a deep scan. Data recovery specialists may look for suitable blocks of unallocated data close to the first extent and attempt to patch the file together, but this is not a job for Recuva.

What exactly is your problem? Have you done everything advised in this thread?

Recuva only reads the first extent of a file with deep scan (subsequent extents are not identifiable). So any file in extents will not be complete. A Recuva deep scan runs a normal scan first and does not return the files found with the normal scan during its deep scan phase. Recuva returns whatever is in the clusters on the disk, bit by bit. It does not change or interpret any data.

Recuva is a tool for recovering deleted files (although it will list live files) and you don't have any deleted files. It asks the file system to read the device, it doesn't, and can't, start reading alternate blocks or error coding or whatever. As I said if you could read the disk you wouldn't be using Recuva. In other words Recuva doesn't work miracles. What happens when you use Explorer to read the disks? What sort of damage is on the disks? Can it be polished out?

I know that a file can't actually be deleted from a CD, deleting them hides them from the standard display you get with Explorer, and there's not a lot of software around that reads deleted files on cd/dvd's. If the cd is damaged, which is another case entirely, then if the disk can't be read I can't see what Recuva or anything can do. If you can't read it physically you can't read it full stop. After all if you could read the disk then you wouldn't be fiddling about with Recuva, would you?

CD-R and not finalised. I dumped backup data on them and then discovered I'd dumped a file I didn't want backing up, so I added another file and deleted the unwanted file (the cd writing software I use, Ashampoo, doesn't let you delete a file on it's own, I don't know if all s/ware does this). I think the whole lot is rewritten with the new file added and the old file removed, but I'm not sure. It might just rewrite the session header.

Recuva does - or it did - recover optical drives. I tried this shortly after the option came out and it worked well. What I couldn't really grasp was why anyone would want to recover from a cd/dvd, you can't delete anything accidentally. I've just tested it again and Recuva does scan and recover from optical droves. Yes, I do have cd's with deleted files on them. Although this may be so I think that expecting 'defective CDs and DVDs' to be readable is perhaps optimistic.

https://forum.piriform.com/index.php?showtopic=47591&hl=

I thought I'd answered this but I obviously hadn't - probably put off by the OP not bothering to read the documentation. OK then, I'll do it for you. There's no way to filter on the file state or size. In Advanced Mode you can sort the results by state, which will put all the Excellent states at the top. Then you can do a mass select on the Excellents. You can also sort on size in the same way, but not both state and size.

The only options there are with Recuva are normal and deep scan. If you don't enter any selection criteria (and I advise that you don't) then Recuva will return all that it finds. There are no tweaks to find further files. There may well be no further files to find. Although there is a lot we don't know: What is your O/S What format was the disk before the problem What is the new format (with a $BadClus file I suspect NTFS) What exactly does a quick format do, especially with an SSD Does the disk controller handle formats on an SSD any different from a HDD Are you using Recuva in Wizard or Advanced mode What selection criteria are you using the answer to these will not necessarily bring any great break-though. If you think that other software would bring better results then by all means try it, but in the end none of us know what's on the disk and what the software (including Recuva) is actually doing.

It is not possible to restore the file structure with a deep scan. The deep scan finds files only. The file names are held in the MFT, and the directory info is in the MFT also. In fact directories only exist in the MFT. A deep scan runs a normal scan first (which scans the MFT) so you will see some file with names and directories. Even with a normal scan if the directory entry in the MFT has been deleted and overwritten the directory structure will not be able to be reconstructed, and you will see a ? in the path showing this.

$BadClus is a system file so will be of no use in recovery. I believe it was used to hold bad cluster remapping before all that was done at the disk controller level. My few remaining memory cells say that it might be a sparse file, so the 447gb size might not represent actual space used or content. I would scan for all file types and not put anything in the File Name or Path box. 'It is set to 1 pass simple overight (Does it need to be set to another setting).' Ignore this. This option is specifically for overwriting files - the last thing you want to do.

Indeed yes, but that's a list of files found, not recovered, which could be but is not necessarily the same.

Don't keep us in suspense. Where is this log?

In my experience CC will only clean known temporary data on the C (system) drive, and it will not by default delete any user files. The only way I know to delete user files on a non-system drive is to specifically include the folder/files with Include statements (but you don't have Custom Files/Folders checked), or to run an erase drive command from Drive Wiper. This is assuming that the D drive contained user files instead of, for instance, a redirect to hold only temp internet files. There's no way to undo file erasure done by CC. Whether anything can be recovered from the D drive depends on what's actually happened to erase the files.

I guess that Recuva works on a write as little as possible to the drive principle, so no, there's no log of recovered files. It is usual to recover to a new folder on a different drive/partition, so if this is done there are ways of listing the contents of that folder (even Recuva can do that, albeit in a rather fiddly way).

They are the index files from the recycler. When files are sent to the recycler two files are created, the data component (with a name beginning with $R) and an index component (beginning with $I). Both have the .jpg extension. The index is 544 bytes long, and is useless as far as recovery is concerned. You need to look for files with $R names, or with a length consistent with the original jpg files.

It is possible to enter an extension in Advanced Mode, Filename or Path. However the scan time will remain the same, as Recuva has to scan the entire disk, or MFT, to make sure that all items are found.

Unfortunately if Recuva is not responding then it will have to be run again. Are you recovering to your 2TB drive or other drives?

Have a look at http://www.piriform.com/docs/ccleaner/ccleaner-rules

Isn't it the other way round. Mta? The 'end of the drive' is at the centre of the disk (or as far as it can get within the partition). These are the high numbered sectors/clusters. So top left of the map represents the outer tracks, and bottom right the inner tracks. Of course the map is a logical construct created from the MFT, unless you're using rectangular disks.

Recuva needs a drive letter and to be able to open the partition. It recovers at the file level. The only software I have (limited) experience dealing with at the partition level, and seems foolproof, is Partition Magic. Google will get you there.

I've really no idea. Your one file shown had zeroes in the header, so nothing can be recovered from that, in practical terms. Of course my theory might be nonsense, but unless someone more androidish comes up with another it's all I, or we, have.

If the header of all the files contains zeroes, as in your example, then there is no picture to recover or display. The card is most likely formatted as FAT32. On file deletion the file system sets the first two bytes of the file's address to zero, giving a false address to any file with a starting cluster address above 65,000 (I can't remember the exact number). That is, with a 4k cluster size, around 250 mb, so just about everything. In your example the cluster start address is 15,883, which is within the 65,000 and is possibly a 'chopped' address now pointing to free space. There is no way to reinstate the deleted bytes of the addresses. A deep scan might find some of your pics, if they are not fragmented. It's worth a try.

I wouldn't know an Android if one hit me on the head, but a Google search (which I recommend to anyone) certainly gives the impression that the data has gone forever, if the card has been formatted as internal storage anyway..