Jump to content


  • Posts

  • Joined

Everything posted by Augeas

  1. There are many reasons why this happens, few with a good outcome. First of all Recuva follows the cluster addresses held in the MFT or FAT. Whether the clusters it finds have any relevant data can't be defined by Recuva. What's in those clusters, good or bad, is 'recovered', i.e. copied to another place. The status of excellent, or not overwritten, is exactly that, no live file - at this moment - has overwritten the deleted data. Again it doesn't indicate anything about the value of what is recovered. If the storage device is an SSD then forget recovery, the SSD controller will have purged the data. Recuva can still recover the clusters but they will be full of zeroes. If the storage device is FAT32 then it's difficult to recover, the O/S will zero the first two bytes of the cluster address, recovery will return incorrect clusters. Lastly, I don't know an O/S that assists in deleted file recovery, it's not why they were written. No software can guarantee deleted file recovery.
  2. I'm not sure if I should delve in here, but if each O/S has its own partition, which is implied in the first post and as far as i know is mandatory, then each O/s should have its own registry, set of files etc. The idea that an application on one O/S can access a single bit of data held on another partition is to me, the way to madness. There has to be something here that I, at least, can't grasp.
  3. You could try... Open Recuva, if you are in wizard mode close the welcome window using the top r/h x. This should put you in Advanced Mode. In Options/Actions check the Scan for Non-Deleted Files box and the Restore Folder Structure box below. Run Recuva on both partitions, it will be quite fast. If this finds your files then you can restore them to somewhere safe with folder integrity maintained. You may also restore some deleted files as well, but this is a small price to pay. You can recover all files found to be safe, but those files with no folder strucure (all under ?) will be deleted files, as all non-deleted files should have an intact folder structure. It's worth a try.
  4. 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.
  5. £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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.)
  12. 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.
  13. 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?
  14. 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.
  15. 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.
  16. 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.)
  17. 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.
  18. Because your drive is an SSD, and WFS is pointless on an SSD. And WFS three passes on an SSD is three times more so.
  19. That's nothing to worry about, it's only 500,000 live and deleted files. On my 120 gb C drive SSD my MFT is 472 mb, and I am only using 36 gb. Win 10 install allocates and deletes a lot, a very large lot, of files. Remember that large files, and large directories, will use multiple MFT records so the total file count is probably under 500k. WFS will not touch the MFT, unless it's an entire disk erase. Windows does not reduce the size of the MFT, nothing does, apart from a reformat. When a disk is nearly full then NTFS will allocate files within the MFT Zone, which is not the same as reducing the size of the MFT.
  20. You could read through http://kcall.co.uk/ntfs/index.html although it is heavy going. The part headed MFT Records, or MFT Extension Records, describes the index clusters (called Folder Entry in Defraggler) for a file, the principle is the same for a folder. Microsoft sometimes calls directories indexes, and we call them folders. It is confusing. The MFT is a file, which holds one or more 1k records for every file on the drive, including itself. A folder, or directory, consists of one or more records in the MFT. Large files, or large folders, may have separate index clusters allocated which hold the addresses of the many MFT records used by the file or folder. Yes, I have noted your signature, and agree entirely. We're a long way from Recuva Suggestions, but it's fun, sort of.
  21. Yes it does. Use a hex editor to find a directory record in the MFT. You will see that file names are held in ascending name order in the $Index_Root attribute. Delete one of those files and the remaining file names are moved up to fill the gap and an EOF marker overrides what was the last file name. Larger directories will have MFT extension records, and one or more Index clusters. The principle is the same. This is easy to observe with a small directory, and I have. There is no process I know that can flag a file within a directory as deleted. Show me an MFT directory record containing a deleted file. Yes it would. Recuva doesn't look at the directory records, so it doesn't matter what's in them. Recuva looks for deleted FILE records in the MFT, and lists those. Deleted files are not listed in directory records in the MFT. Directory information for a deleted file is found by following the directory chain-back address in the deleted file's record. (As far as I understand from my experience using Recuva.) If you run Recuva you will see many deleted files listed that have no directory information - the directory records no longer exist, but Recuva finds the files. This is a misunderstanding of the structure of the MFT and what has been said here. No MFT records are shuffled anywhere, nor has that claim been made. The shuffling is of file names and associated info within the MFT records for the directory, not MFT records themselves. My three other replies stand. These are unallocated MFT records. They are not the same as file names held within a MFT directory record. I'm beginning to wonder whether the terms 'MFT' and 'Directory' are being confused?
  22. These Folder entries are the index clusters for large folders as described in my previous post, and indeed as described in https://www.ccleaner.com/docs/defraggler/defraggler-settings/defraggler-options-advanced-tab However the topic is Recuva suggestions, not Defraggler, and Recuva cannot amend the size of a directory, which includes these index clusters.
  23. You're quite welcome to disagree. An NTFS directory is a record in the MFT. A large directory may have several MFT records. An exceptionally large directory may have a separate index cluster allocated. I don't know whether we are using the same definition for directory. By the way I have just edited my big response, please use the later version. More by the way, no, I have never used Defraggler.
  • Create New...

Important Information

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