Jump to content
CCleaner Community Forums

Augeas

Moderators
  • Content Count

    4,368
  • Joined

Posts posted by Augeas

  1. To answer your question CC will, if you absoultely force it to, fill the disk with zero-filled files, and then delete them. However CC will warn against this, and indeed it is utterly pointless, achieves nothing, and will hammer the MFT and other system files. It does not even 'fill' the device. It is not, as you imply, 'the ONLY way to "erase" anything from solid state memories'. There is no way, using O/S software. TRIM will do it all for you.

    There's a lot here that is shall we say contentious, but I'm not going to get into a lengthy exposition. If you want you could read through  http://kcall.co.uk/ssd/index.html which goes into considerable detail, even though it is still being updated. You could swap ssd for ntfs in the url for even more bed time reading.

  2. It's been suggested a few times before, and although there is a likelyhood that some file will be modified or unavailable on a restart, that also applies to a certain extent when running Recuva anyway. I doubt if will be implemented, given how many times Recuva has been updated recently (around zero).

    I can't see any real reason why you should not work on your system drive whilst running Recuva. It will slow things down a bit but I'm sure you can live with that.

  3. Well, I can't open my files is pretty unspecific, and we're not clairvoyant. At a guess I would say that the files do not contain a correctly formatted header. Recuva copies clusters bit by bit with no alterations, so what's recovered is what's on the source disk. The reasons why the header is not what is expected could well be found in the somewhat slighted file (which saves typing it out every time we get this question).  But I'm no expert.

  4. You're not doing anything wrong. With TRIM, which I would expect most O/S and drives have now, deleted clusters on an SSD are immediately mapped to a default zeroed cluster. The deleted data cannot be recovered by any means. Recuva will find the deleted file names and cluster addresses in the MFT, but the data has gone forever. If you look at the Recuva Info pane in Advanced Mode then the headers will contain zeroes. Unfortunately nothing and no-one can retrieve it.

  5. Deep scan will not find text files as they do not have a file signature thus the scan can't identify them as files. A normal scan (which runs before the deep scan) can find them (if the MFT record still exists) as it scans the MFT and the MFT holds the file name and cluster addresses of all files on the drive. If the text files aren't being picked up by the normal scan then there's little hope of retrieving them.

  6. None of us would be so fooish to wipe free space on an SSD, would we?

    We don't really know the mechanics of wiping free space (CC's mechanics) but we're pretty sure it allocates a large enough file to fill the disk and then deletes it. How is that file allocated? I would hope in big chunks for a start, but CC's code dates back to cro-magnon times so we can't really be sure. If it allocates initially in 1 gb chunks then the MFT record will very soon be full, and an extension record allocated. And another, and another, and then an index record, holding all the addresses of all the MFT records. The MFT record(s) for such a file could be horrendous. As the disk fills smaller allocations would be necessary, to grab the smaller spaces. More MFT mayhem.

    I think that the optimun conditions for a WFS would be if the free space is defragged first. Then the big file allocation would be eased, big chunks would do most of it. Small free spaces can, as I know, be missed by WFS. The process seems to allocate in minimum 32k or so chunks.

    P.S. Are you running WFS in Options/Settings or Drive Wiper? If in Options did you check Wipe MFT?

  7. The MFT record for a folder contains the addresses of the MFT records of all the files in the folder. The MFT record for a file contains the address of the owning folder. When a folder is deleted NTFS removes the addresses of the files. Recuva reads the folder address in a file's MFT record to locate the owning folder, chaining back all the way to the root (if the chain is still extant).

    If a ? is shown as a folder it means that the backwards chain to the root cannot be completed, probably because the MFT record for that folder has been overwritten.

    Nobody knows whether you can recover 'this file' with Recuva or any software, we don't even know its name. Judging by what's been done to the drive I would doubt it, as I've said twice before.

  8. It appears to have located a folder. Recuva doesn't list folders explicitly, but lists files and then builds up the folder structure (if required and requested) in a chain-back process. Deleted folders, as far as I can establish, are cleared of their list of files by NTFS, so finding a deleted folder is of little use, it's just a name. You are of course free to use whatever software you want to aid any file recovery.

  9. Simple cleaning appeared recently. I decided to use it, but I did not think that after that all accounts and the history of visited sites would be cleared. I am very upset, now I will again have to recover all logins and passwords for autocomplete. When using simple cleaning, I did not see a single indication of such consequences, it was not indicated what would be cleaned when using it. I suggest you display a warning about clearing browsers data.

     

  10. That's a folder not a file. Perhaps you haven't checked Show Files in Hidden System Directories. To reverse a partition delete and format you need a time machine. I don't know what the other sw does (or even what Recuva does), but the file names and path are all held in the MFT. I guess after a format that you're looking at the remnants of the old MFT that weren't overwritten.

    I should display the results as a List and sort on folder name (after doing the check and rescan as above).

  11. Recuva normal scan will list all deleted files for which a record exists in the MFT, no matter what their name or extension is, or whether they have an extension at all. Deep scan will scan for a specific list of extensions. It will not find files with an unknown, or no extension.

    If a normal scan can't find the file then the record in the MFT is most likely not available any more - reused or overwritten. If a deep scan can't find the file then it probably has an unknown or no extension.

    If it's a very large file (and I would guess it is) then it won't be easy to recover even if it is found.

  12. The deleted files will remain (if they still exist) on the drivre they were originally on. The recycler renames files sent to the recycle bin to two components named $I and $R + a set of random characters + the original file extension. Ignore the $I file, the $R is the one you want. Whether these names are kept on final deletion or reverted to the original does not seem to be clear. If you can't find anything then the files may well be gone forever. You could try a deep scan in this case, but it will not return file or folder names.

×
×
  • Create New...