Jump to content
CCleaner Community Forums


  • Posts

  • Joined


1 Neutral

About Augeas

Profile Information

  • Gender
    Not Telling
  • Location
    Where Stuff is made, UK

Recent Profile Visitors

5,082 profile views
  1. Win 10 has sys restore off by default, so that may be a factor. I don't know if a win update would set the sys restore option back to the default off, but I wouldn't be surprised.
  2. £MFTMirr is a one cluster file containing a copy of at least the first four records of the MFT (larger cluster sizes hold more records). It is a system file to enhance integrity and I would imagine that NTFS would fall over if it were not there. Offsets 0x30 and 0x38 in the Volume Boot Record hold the MFT and MFT Mirror logical cluster addresses. The first two records in the MFT point to the MFT itself and the MFT Mirror.
  3. Formatting a partition creates both the Volume Boot Record and the MFT. If you format a device as NTFS and then quick scan the files with Recuva (check scan for non-deleted files) you will see about 25 live system files, the first being the $mft. The MFT holds the addresses of all the files, including itself, so it must exist before any user file can be allocated. Where it is positioned is due to the formatting process. And if the MFT is already created whatever is done with user files can't alter that. Where files are on a storage device can't be established (easily) by looking at the drive. Defraggler (and any software) creates its drive map by looking at the MFT (where all the file names and cluster addresses are held) and by possibly looking at the cluster bitmap, where each cluster is flagged as being in use or free. Defraggler's drive map is an illusion.
  4. That won't work Willy. The $MFT is created - as are all the system files - at device format time, before any user files are loaded. The MFT is allocated in 'zones' of 200mb chunks, about 50,000 4k clusters, and all except the first zone can go anywhere on the device. The location of the start of the MFT is held in the volume boot record so I imagine moving it (safely) would be quite a problem. I would think that reading a very large file - even if it has been loaded contiguously - would hardly notice the few milliseconds taken to pass over the MFT.
  5. As (I assume) all file deletions under the control of Windows, no matter how executed, use NFTS (or FAT) to process the deletions then yes, Recuva will operate in the same way for rd, shift/del, recycler etc deleted files. Whether you will find or be able to restore those files is another matter, but the deletion method is irrelevant.
  6. I'm sure Recuva could be improved - as could the other recovery software mentioned - but the reasons for your disquiet probably lie with the file system rather than Recuva. No file system has any obligation or compunction to assist in recovering deleted files, especially after a format, which is essentially a clear out and start again process, and is often prefaced with a 'This operation will destroy your data' warning. The reason why you are able to see any user file names is, if anything, that the format isn't particularly thorough. There's no indication of what file system was used. If it's some type of FAT then on a format the FAT tables will be zeroed and the root directory reinitialised - at least. Recuva appears to find the remnants of the old root directory, but the cluster chains held in the FAT will have gone forever. I appreciate that it's disappointing not to be able to recover deleted files, but expecting to to do so after a years-old format is perhaps somewhere between optimistic and disingenuous.
  7. Allocate 15 (or more) files on your D drive with random file names. This will overwrite those file entries held in the MFT. You can then delete the files you created. Of course you will still have the random file names shown, and they may possibly have red icons, but the old file names would have gone. A larger number of files can be wiped by running CCleaners Drive Wiper Wipe Free Space, which does the same thing but replaces the file names with ugly ZZZ.ZZ concoctions. These methods will overwrite all the deleted file names, not just those with red icons. Use of the D drive will tend to overwrite those file names anyway, but you'll still get red icons from time to time.
  8. The point of Recuva is to recover previously deleted files, and the point of NTFS, which I assume we're dealing with here, is to ensure the integrity of live metadata and live user files. The two don't always go together. Recuva reads the MFT and lists all records for files that have the deleted flag set. It doesn't select or exclude any files apart from those options chosen by the user. What you see is what there is in the MFT. If any deleted record has been reused by NTFS then the deleted file's information has gone and can't be shown. With an SSD the process is the same but the outcome is different. Although the deleted file list is still shown very little data is recoverable, due to the way the SSD's controller handles deleted pages. Recovered files will contain zeroes, so using Recuva or any file recovery software on an SSD is likely to be futile. However I have noticed a difference bewtween running Recuva when I had an HDD and when I moved to an SSD. On the HDD the list of files includes many recognisable user files, and there is a good chance of recovering many of them. With the SSD I see a large list of what appear to be system files, and a very short list (fewer than 20) user files. This is puzzling, but correlation isn't necessarily causation.. The only quick explanation I can see is that there are a larger number of dynamic file allocations and deletions taking place that are reusing the deleted user file records in the MFT, wiping out user deletions. When I moved to an SSD I also moved from Win 8 to Win 10. I don't believe that the SSD is relevant here, as it knows nothing of either NTFS or the MFT. NTFS version 3.1 has been the same on disk since Windows XP, so is Win 10 (or Firefox, or both of them) now upping dynamic file allocation? Is it Win updates? I don't know. The point is that Recuva is doing what it always has done, reading the MFT and listing the deleted file records. That it isn't showing what the user might want it to is frustrating, but just how it is. (Put as far as I know before every sentence.)
  9. Because - probably - a deep scan runs a normal scan first, and a normal scan reads the MFT where the file names are held. The file names are listed, but the clusters which held the file's data should contain zeroes, or more correctly a read request will return zeroes (who knows what he clusters contain, they are unaccessible). It is quite usual for files recently deleted being not found. A file deletion leaves the MFT record marked as available for reuse by any activity, and even opening Recuva writes a few files. I have a sneaky suspicion that NTFS reuses available MFT records held in memory first, so a recently deleted file's record is very exposed to reuse. As you say, running a deep scan on an SSD is pretty much pointless, there's next to nothing to return.
  10. I wonder how CC knows - if it does - that these ZZZ files are CC's files and not user files? I could create a file called ZZZ.ZZ and put whatever in there. Is there a file signature?
  11. You must have a different Recuva from me then. However willing the moderators are here they don't write any of Piriform's code, nor do they deny much either.
  12. I don't know what you mean by step 5, Recuva (free) only has three stages . Recuva does not change any attributes on any file on the source drive, so I've no idea what is happening with your drive.
  13. Nobody can say whether you can, or will, recover any deleted files. All you can do is try. A deep scan runs a normal scan first, so when you chopped the deep scan you would have seen the results from the normal scan. This scans the MFT which is very fast. Running a deep scan on the recycler is not feasible, as the directory information is held in the MFT not at file level, and a deep scan looks for clusters containing files, not directories. Files sent to the recycler are renamed, to $Ixxx.ext and $Rxxx.ext. The data part is held in the $R file. You could run a normal scan with $R in the filename box, or just look for $R files. A deep scan will not list the files under this or any name, as filenames are held in the MFT. (I have seen files deleted from the recycler return to their original names, I don't really know what rules the recycler follows.)
  14. FAT32 is a beefed-up version of FAT16. However it needs four bytes to hold the first cluster number (in the FAT tables) instead of two, so it uses two additional bytes from elsewhere (the actual address of the start of the file is held in two separate halves). When a file is deleted the additional two bytes of the address, the high end, are wiped by the file system for some reason, and as a result the address of the file is corrupted. This is why you get the overwritten file message, Recuva is looking in the wrong place. It isn't possible to find the right place, except by guessing. A deep scan looks for clusters with a recognisable file signature, so can be useful in cases such as this. However a text file has no file signature, so is not identified by Recuva. It may be possible to find this file with a hex editor, but as it's only a test it isn't worth bothering.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.