Augeas

Deep scan runa a normal scan first, so tis might be the big files you are finding and having the same space problem with. Deep Scan files have a numerical file name, such as [01234].ext. They will only be one extent and should not give any problem with space (i.e. they will require just as much as there are clusters i the extent). Look for these file names with large sizes (sort the size column).

Files found with a deep scan will have names as [01234].ext. They will not have their proper file names nor will they be able to be sorted into folder order, as this information comes from the MFT, which a deep scan more or less bypasses. Are you SOL? If I knew what that meant I might be able to guess. I'm quite confused by 'I don't need anything I deleted'.

Do you mean that Wipe Free Space in Cleaner is checked? If so, then a drive has to be selected in Options/Settings for this to come into effect. The default for this is WFS unchecked and no drive checked. If you mean that a drive is checked in Options/Settings then WFS in Cleaner has to checked for this to be effective. As the defaults are unchecked then if both are checked then at some time some human intervention was required to make the change. Yes, wiping free space takes a lot of time, and produces an operation complete message. As your run times are about four minutes then I very much doubt that WFS is running. My normal cleaning run staggers a little at 46 seconds, but is over in around ten seconds or so. That cleans around 2-300 mb on average.

There is no size limitation as far as I know. However when a file larger than 4gb is deleted in an NTFS system then there are changes to the file's record in the MFT. The file size and end cluster number are set to zeroes/FF's. If the file is in many extents then any extension records in the MFT will have the data cluster addresses set to zero/FF's. This causes the not-quite-accurate error message. These 4k+ files are to all intents and purposes unrecoverable. They may still exist on the storage device but unless they are in one single extent then patching multiple extents together is impossible without professional help. A deep scan will show whether there are files of 20gb+ found. If so then recover those and see what you have. Otherwise it's back to the previous paragraph.

Regular old ASCII only suports Latin characters, and half the world uses some other script. I'm no expert, but to quote Wikip ' UTF-16 is used for text in the OS API in Microsoft Windows 2000 onwards', and ' UTF-16 is the native internal representation of text in the Microsoft Windows NT', which is the same thing I guess. So UTF-16 is what Windows uses. The duplicate file txt output has a byte order marker of FF FE indicating that it is little endian. Wikip again '... the application is expected to figure out what encoding to use when reading text data.' The duplicate file txt output is openable by Notepad, which reads the byte order marker amd interprets accordingly. I don't know why Cygwin can't do the same. I think that the bug lies with an application with a name beginning with one C.

Driove Wiper will delete these files when it's finished. It's the way that wiping a drive works.

Although you ran a deep scan the info (very handy, I wish everyone would do this) shows details returned by a normal scan (Recuva runs a normal scan before a deep scan). A file found during a deep scan has no file or folder name, and only one primary extent. The info here is taken from the entry in the MFT. The file header seems to have the correct four-byte signature for an MKV file. I can't say whether the rest is valid, but I would assume that if the file signature is intact then it's likely that the rest of that cluster is intact also. But I could be wrong, of course. There are enough clusters to make up 3gb too. The file header comes from the start of the first data cluster. With TRIM enabled the deleted data clusters should have been cleared. Is TRIM enabled on this drive? Apart from that I'm running out of ideas. After around byte 140 or so the header is zeroes. Is this relevant? Is the rest of the file like this? I don't know. Ultimately Recuva will just recover - copy in other words - whatever is in the allocated clusters, so there's no tweak to do it any better.

Safe? Well, it's very unlikely that you will die. It is however pointless as you cannot physically overwrite a nand flash page. You will also force the SSD to do a huge and unecessary amount of page writes and deletions, which is a waste of time, electricity and a little bit of the SSD's life. That's why you are getting the warning. With TRIM enabled you should find very few deleted files using, for instance, Recuva. Those that are found will be mainly small files held in the MFT, which wipe free space will not remove anyway. A far better process it to run an occasional defrag Optimise, which will TRIM any deleted pages it finds.

Is it the system drive you're recovering from? Is it NTFS or FAT32? Recuva can search for non-deleted files if the option to do so is checked. Recuva can also overwrite deleted files if specically asked. It does not erase anything when it's closed, and will never overwrite live files, even if you asked it to. If the drive is NTFS then the excellent files should open, in the main. How many files do not open (empty boxes, as you say)? Files marked as excellent can be corrupted, if (for instance) a temporary file is written on top of the deleted clusters and that file then deleted. After three days I would not expect this to apply to many files. But if it's the system drive and a lot of browsing has taken place then I suppose it's possible.

1) You an recover the files to anywhere you want, except the 'source' drive. Recovered files are copies of what's on the source drive. I'm not sure what you mean by ' is there nothing at all on the drive that I was trying to recover?'. All the found files come from the source drive (the drive you're trying to 'recover'). 2) No. Recover the files and then decide which are to be reinstated on the source drive. Well, that's the correct advice, but as you're recovering a backup drive you could recover all to your recovery drive, recreate the partitions on your backup drive, and then replace your recovered files. The problem with this is that you will be reinstating a lot of junk along with the good stuff. 3) Yes - ish. In Recuva Advanced Mode select Options/Actions/Restore folder structure. However this will not work with files found with a deep scan that have a number instead of a name, as they hold no folder information. If you have a list of file names then these should be in folder order, if that is possible. 4) Perhaps. In Advanced Mode Options/Actions check Scan for Non-Deletred Files. This might, just might, give you better results. Try it without a deep scan as it is vastly faster that way.

I don't think that there's a way to do this. Recuva will just put a (2) suffix on duplicate file names. How did you do the original selection, are you repeating this? You could always dump the first lot of recovered files to DVD and then plough on, depending on how many gb you are recovering. Or buy a big flash drive and dump them there.

First of all the free and the paid versions both have the same recovery capabilities. Secondly those 'empty boxes' aren't going to right themselevs in a Newtonian world. But don't delete what you've recovered. Don't delete anything until the recovery is finished, or abandoned. I asume your drive is NTFS? Did you do a normal or deep scan? How long has it been since the folders were deleted? In Recuva's list of found files, those marked as overwritten or partly overwritten will not be recoverable, or not be completely recoverable. With a deep scan nothing is overwritten, but only the first fragment of a fragmented file can be recovered, so some will be recoverable, some won't. There's no magic in recovery: Stop using the drive for anything except the recovery. Run a normal scan, sort by state, and recover all those marked as Excellent. (You could also recover those marked as poor, some might be usable.) Run a deep scan, select by .jpg, recover all. Many will be unusable, some will be good. When you've done spend £20 on a pack of DVDs and half an hour on accasional backups.

I'm not aware of any such proposal.

No, not according to the documentation and my 10+ years experience.

As you say card I assume the file system is FAT32. If so then (regulars will be getting bored with me repeating this) on file deletion the file system will zero the first two bytes of the file's cluster address, making the file inaccessible. If you look at the info pane on the right for each of the files the cluster address may start at under 65,535. If this is so then this indicates that the cluster address has been zapped. This will explain why four of the files appear to be overwritten by the fifth. their adresses are now pointing to, or near to, the start of the fifth file, which has a valid address. Unfortunately there's no trick to resolve this. The values in the first two bytes are gone forever. The files will still remain on the card in their original position, but are difficult to locate. If you run a deep scan and look for, and recover, any files with a similar size of the four 'lost' files, then you just might, just might, be lucky. Any files that are fragmented will not be able to be recovered in their entirety, as only the first fragment can be identified. It's worth a try.

And if you've solved it, please tell us how so we can become just a fraction more knowledgeable.

For what it's worth, I believe that Windows defrag doesn't include large fragments (I think it's 64 mb) in its defrag count. So if a file has fragments larger than 64 mb it isn't classed as fragmented. I've no idea what Defraggler does. Personally I'd forget it. Why chase your tail for something that won't last five minutes and has no noticable benefit at all?

Please do not use insulting language on this forum. Last warning.

You can sort the Path column by clicking on the column header. You can then find the desired path, highlight or check all you find, and recover to a folder on a different drive. If you have sub-folders then in Advanced Mode/Options/Actions check Restore Folder Structure (ignore the Secure Overwriting box). Alternatively after the scan enter all or part of the path in the Filename or Path box (in Advanced Mode) in the form of users\name\documents for example. Then check all by checking the box next to Fiklename and recover as above. This is the easier way if the folder has very many files.

And what was that, I wonder?

I don't have any good news. SSD's are a nightmare for recovery, too clever for their (or our) own good. When a file is deleted on an SSD a TRIM command is sent to the SSD which tells the device controller that the pages are no longer needed. The controller then unmaps those pages (and effectively replaces them with a page of zeroes). At that point the previous data is irretrievably lost. I think that this explains the zeroes in the headers. If the device were USB attached then the TRIM command might not be passed to the controller, and there would be a chance of recovery, but the zeroes do not bode well. Files are listed because Recuva reads the MFT and gets the file list and page addresses from there (TRIM does not touch the contents of the MFT). Unfortunately the address of the old data is of no use. Have you put any filter i your scan? If so I would rescan with no filter at all so you retrieve all deleted files. Did you run a deep scan? If not do so (yes, with no filter). You might find some edit copies etc. Do you have any shadow copies listed in Recuva? If so I would scan these. In advanced Mode Options/Actions check scan for non-deleted files, again not putting any filter in the scan. After the scan enter yourname\documents in the filter box to reduce the list. I have tried this and the results were not as good as I expected, with most pics chopped or distorted. As soon as you find anything recover it to a folder on another drive. Good luck.

Have to go out now but it looks as if you're right, can't see my serial no at first glance.

Well, that just goes to show how I can mis-read a post. I'll have another look.

Yes, still there in the same place using Speccy 1.31.372 PS I am using the portable version, although I can't see that making a difference..

Yes, uder Storage/Hard Drives the first disk is specified, and the tenth entry is Serial Number, between ATA Standard and LBA Size. My speccy is 1.25.674, which I downloaded a couple of years ago and tested, and didn't bother with it anymore. I'll download the latest vers and try that.