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.
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.
Put files that have already been recovered in correct directory?
Yes they will (minus any that have been overwritten by subsequent activity on your pc). Recuva copies deleted files to another device, they are untouched on the source device.
Unfortunately you'll have to re-run the recovery with the correct option selected.
File's data not on disk means that the cluster addresses are not valid, they are probably set to 0xffff. There's no point trying to follow these addresses. You may find your files with a deep scan, if, at the end of the scan, you filter for file type and date, size etc. But this is a long job, and if you find a file only the first extent will be recoverable without professional help.
Recovery is not actually recovery, Recuva (and other recovery software) will copy the contents of the deleted clusters exactly as they are to a folder on another device. If a header is seen as corrupted it means that the cluster contents don't match the heade specification for that thype of file. In this case it is unlikely that the rest of the clusters will be viable either. In the O/P's case a header of null (zeroes) almost certinly means that the file has gone forever. In other words I don't think it's just the header that's been lost.
Were all those files listed created (4 Aug) after the format? Did you delete them straight away? Where are the files overwritten by files created before the format? Are they the seven at the top of the list? I've never known a deleted file to be overwritten by anything other than a live file. I am guessing that: During the format the new root directory was written on top of the old root and has pre-allocated space to keep it in one extent. The previous file names in the root directory are thus available to be read by Recuva. ExFat is significantly different from FAT32 as it no longer uses the FAT to identify used space, this is done by a cluster bitmap. FAT entries are no longer zeroed on file deletion or (I assume) a format. If a file uses contiguous clusters then the FAT is not referenced at all. I think that Recuva might be getting confused over non-zero FAT entries and deleted clusters shown by the bitmap. None of us actually knows Recuva internals and I bet a pound to a penny nobody knows how ExFat works either, as it is proprietary software. I should write it off as a curiosity.
Probably because both devices are classed as SSD's. Actually I'm surprised that you were offered one pass, unless that one-pass segues into an Optimise when it's run. It is not physically possible to overwrite an SSD page. If you have TRIM enabled on your pc and storage devices then you do not need to do any wiping on an SSD. The deleted pages will be 'wiped' by the SSD controller, and an occasional Optimise is all that's required. A multi-pass wipe on an SSD is madness, which is most likely why it isn't offered. Oh yes, the same goes for secure file deletion. It is invalid on an SSD.
If you cancel now (assuming that it hasn't finished) then all the files found so far will be displayed. There's almost 3.25 million for you to play with, although not all will be shown unless you have the show live files option checked. It won't make any difference to recovery if Recuva is cancelled or not. Files won't be recovered any 'better' if the run has completed. If recovered files won't open or play then the chances that they ever will are slim.
This 'file is overwritten by an earlier file' is common for a deleted file in FAT32. However you're almost certainly using exfat so that might not apply. I am not familiar with exfat structure, nor the deletion or your camera's formatting process. It seems strange that after a format these user files can be seen, as a format should (and will) empty the root directory except for any system files. As for replaying them, if they're overwritten then not a chance. You'll be recovering, and trying to play, part of an entirely different file. Is that large file 32gb?
Doesn't it? I can see it quite well, and there's no indication that it is hidden.
If you're using the Wizard, switch to advanced mode (top r/h button). In advanced mode select Options/Actions. Check boxes 1, 2, 3 and 5. Leave box 4 (Deep Scan) and box 6 (Restore folder structure) unchecked. Press OK. You should not need to do another scan. With nothing in the Filename or Path box you should now have zero files ignored. Thiws advice is for a non-formatted device, reading back I have to repeat the caveat in my last post.
Does Recuva show any cluster numbers? I am surprised that a live file is listed by Explorer as 2.9 mb and yet appears to have no cluster addresses associated with it. That is a seriously screwed up folder entry. If there are no clusters shown by Recuva than none can be recovered.
Recuva hang on at 16% for more than 1 day !!!!
A normal scan on a 2b device should take no more than a few minutes. if that. I can only guess that there is some problem with the device that is either sending Recuva in an endless loop, or Recuva has stopped completely. I would cancel the scan and see what results you get.
Now we learn that the drive was formatted and it's some Android device, I am not familiar with Android O/S at all.