Augeas

I have a very old version of Speccy and it shows the serial number in the XML extract, about 10 down in the disk section. Does your version not have this?

There's no correct or incorrect, it depends on what you want. Normal file deletion has no part in wipe free space. As you are running wfs from Options/Settings it will do one pass of zeroes. Checking Wipe MFT will obviously take more time, depending on the size of the MFT and how many invalid records it holds. The rest is due to the size of the disk and how much free space there is. Possibly the fragmented state might increase the total time as well. Also when you run wfs you are running the other cleaning processes as well (unless you right click wfs in Cleaner and select Wipe Free Space, which runs it alone). As you have selected normal file deletion this shouldn't take too long, but still has to be accounted for. Wipe Free Space, simple overwrite, within Drive Wiper will do a stand-alone wipe so you can see how long it is really taking.

No. If you are in Wizard mode, just click on the Switch to Advanced Mode box in the top right corner.

Are you using Drive Wiper or options/Settings? I would think that the time for wiping free space depends on the disk size, whether wipe MFT has been checked, and how many passes have been selected. I haven't personally noticed any increase in time with the same disk size and options.

In Advanced Mode the Info pane will show the full comment for each file.

Please do not double post, GMV.

Recuva recovers (copies) whatever is at the clusters at the address held in the file header. Word will attempt to open the file, and if the file isn't in Word format then it will fail. As Mta said, what is the file system, how long has it been since the file was deleted?

My tests have been on FAT32 only, and I can recover a deleted directory back to the root (they were simle tests however). I think that success depends on the circumstances of the individual.

I believe the 'problem' here is that when you plug a device into a USB slot it communicates with the system using the USB mass storage protocol. It simply doesn't support SMART (which is an ATA command). A USB attached hard disk is no different from a USB attached flash drive or SD card, or anything that has a USB plug on the end of a cable, they use different protocols. The system doesn't know what sits on the other end, it may not speak ATA at all. Some protocols, like the one used by USB hard disks, allow ATA commands to be passed through different protocol layers, but there is no general protocol to speak to those devices, and it's probably not supported by WMI, because it's a very complex task. Speccy, like the other Piriform applications, I believe only use WMI requests, so SMART data is not available from USB connected devices. As I said I'm no expert (and this was mainly cribbed from an article in StackOverflow) so I'm quite amenable to being corrected, as I'm at the limits of my knowledge on this subject..

The list isn't saved. If Recuva were accessible then the list could be saved as a text file, to be used as reference only, not as input to the recovery process. i remember Recuva when it was under 1 mb in size and disks were around 150 mb. Now disks are three terabytes, that's a lot to bite off and chew. As Recuva doesn't write to the source disk it must write its data to ram. I don't know the size of the saved info for each file but with 12 m files and ram up to 12 gb it must be well into the hundreds of bytes. There's no upper limit to the disk size Recuva can handle, but there must be an upper file/ram combination, and it looks as if you're hitting it. As Recuva will always scan the entire drive whatever scan options you choose I don't really know what to suggest to proceed further, apart from killing every other process you can whilst Recuva is running. I'll have a think overnight.

I've no idea. You'll have to look for yourself.

No, the scanning and recovery processes are identical.

CC's normal file deletion is just that, the equivalent of a shift/del, so any of these deleted files could be recovered before they are overwritten. If you have secure file deletion checked then the files that CC deletes can't be recovered with or without software. However there are log files, journal , and probably other places that contain some file data, which have been the downfall of many a poor lad. CC isn't a forensic cleaner, but it's good enough for me, and I'm mainly concerned about passwords and banking details. An occasional wipe free space, with a wipe MFT if you want, followed by a Recuva deep scan, select all, overwrite all, is a reasonable procedure, in my opinion. As SSD is far more secure than a HDD, and an occasional optimise should suffice. Many people are paraniod about erasing deleted data and will go to great lengths to smite it asunder, but take few precautions about securing their live data. It's always been a puzzle to me.

The files beginning with $ are system metafiles and cannot be recovered. Recuva can 'recover' them in the sense that they can be copied to a new location, but they will remain as copies, as they cannot be reinstalled over the existing metafiles. As far as I remenber $BadClus is a sparse file. meaning that it theoretically extends to the whole size of the drive but in fact it is zero bytes. It is not used nowdays as bad cluster control is managed by the disk controller. All this might be moderately intreresting, but is academic due to the above. To find as many files as possible I would not enter any selection criteria at all, apart from the drive letter. Switch to Advanced Mode and in Options/Actions check Restore Folder Structure (ignore the fact that this seems to relate to secure deletion, it has nothing to do with it), and then save the lot to a folder on a different drive. As you are looking for live files I would do as you have, checking Scan for Non-Deleted Files, and not do a deep scan as this only searches for deleted files. I suppose you could check deep scan if you're desperate, on a drive of this size it wiouldn't take too long.

Google will tell you all you want to know.

The ? means that the owning folder (in this case the folder that held WhatsApp Video) has been deleted and Recuva can't rebuild the folder chain back to the root. I'm afraid that you'll have to do what you can with the files that Recuva has found.

As I assume English is not your native language there’s a lot of confusion here. I can’t really understand your last two posts. Recuva will reconstruct all the valid directories in a path up to the root. Right click on the list of files found and select Tree View to see what you will get. As you’re recovering from a ‘USB key’ I assume that it’s FAT32. It would be pointless 'recovering' a directory. The contents would be invalid, and it won’t work across different O/S’s. If the directory path can be established then Recuva will reconstruct it (if you select the right option). If the path can’t be established then no software is going to invent a path. If you really want to recreate a directory then right click in File Explorer, select New/Folder, rename it, and away you go.

Wow J, over three years to respond to a post, this is a super-necromancy thread.

You can switch from Wizard to Advanced Mode any time, there is no cost implication. It will not show you any more drives than the Wizard does. Why would you ‘pick the partition at the beginning of the drive’? The O/P was referring to an external drive with no indication of whether there were multiple partitions. You seem to think that as one of your drives hadn’t a drive letter then later had one that Recuva caused this. Recuva does not go around allocating drive letters. This behaviour can happen with a failing disk. You have already run EaseUS against this disk and that caused the drive to ‘no longer be recognized’. Recuva does not rewrite any part of any drive it is recovering from. It’s unclear (to me) whether you chose to make a disk image, which the pro version can do, and if you did where you created it. You seem surprised that you had 9 drives on your system. To be honest I’m not quite sure what you were doing.

No, you don't need to buy a licence. The recovery process is the same in the free and paid versions. My theory for your problem is: When Recuva scans for deleted files it gets the filename, cluster addresses, and overwritten state from the MFT, not the storage device. If the file has been inadvertently deleted then a TRIM command may have been issued which will unmap the data clusters. The cluster address willl still remain in the MFT. Recuva can retrieve these clusters, but they will contain zeroes. Is this what you see? As far as I know, which isn't very far, an encrypted device needs to be opened before it can be read, so Recuva should not have a problem accessing the deleted files. Do you get a message saying that access is forbidden? Someone with knowledge of this needs to chip in. The chances of file recovery on an SSD are not good, due to the use of TRIM to unmap data clusters, which means they are gone forever.

JD, nobody minds you complaining about Piriform's products, but please do it in one thread. Posting in multiple threads is tedious, repetetive, and won't get you any more or better answers (I have a feeling that you're not looking for an answer anyway). I haven't the time at the moment to respond to any of your posts but your first offering - at a quick read - seems riddled with errors and misconceptions.

Well, I'm glad you managed to recover your data, as far as I can tell you found it within the pagefile. That's a lucky find, I would say.

Whether you buy the Pro version is up to you. It doesn't offer any greater, or better, data recovery processes nor does it solve the file type problem. There are plenty of posts on that subject if you do a search. There is no guarantee that any data can be recovered, from any recovery software or technique.

What's not quite true? Overwritten (0) means that the cluster at offset 0 in the cluster list for this file (i.e. the first and only cluster) has been overwritten. I assume that you have now recovered your data by another means.

It's as it says. The deleted file's one data cluster has been overwritten with another file, so is unrecoverable by any means.