Jump to content

Augeas

Moderators
  • Posts

    4,542
  • Joined

Posts posted by Augeas

  1. First of all I apologise to Legendarysnake for pinching his thread, and for not offering any solution. Perhaps Defraggler is still using the old transactional defrag API's and this causes the slow progress on large drives, but I don't know enough about this to go any further. My advice is that if you are having problems with Defraggler then revert to Windows defragger, or Storage Optimizer or whatever it's called now. It's free, you have it, and it works.

    Right. I don't know if this is due to the vagaries of English language, or the difficulties of expressing oneself accurately and concisely (yep, that's me), or some misapprehension somewhere, but there's a lot here that's confusing.

     

    3 hours ago, nukecad said:

    Getting all the used clusters into one contiguous piece is consolidation.
    A 'Cluster' is a specific defined area on a disc, not parts of a fragmented file. A file is fragmented because it's split over one or more disc clusters.

     

    A disc from the factory is formatted ineradicably into sectors of a specific size. A cluster is specified when formatting with NTFS as a multiple of contiguous sectors. My 500 gb disc, for instance, holds around 975 million 512-byte sectors, and around 122 million 4096-byte clusters. Clusters are addressed by LBA's, as can be seen with Recuva. Like the drive map, clusters are a logical construct.

    A file is one or more clusters. If a file has multiple clusters allocated, and they are contiguous, the file is not fragmented, or if you like it has one fragment. If the clusters aren't contiguous the file is fragmented. Defragmentation is reallocating the file's clusters so that they are contiguous.

     

    2 hours ago, nukecad said:

    For years defragmenters have been doing consolidation, and so that's what people have come to think that defragmenting is.
    That's not exactly wrong though - consolidation is 'defragmenting whole clusters on a disc' as opposed to 'defragmenting individual files'.
    One is concerned with clusters, the other with files.

     

    This is unfortunately incorrect. You cannot 'defragment.. whole clusters on a disc', it doesn't make sense. You can only defrag files, and files are constructed of one or more clusters. A cluster only holds data from one file.

     

    2 hours ago, nukecad said:

    Most defragging apps have a drive map, people like to watch as it moves things about.

    It wouldn't be as dynamic if it was just defragmenting the files.
    You can see that if you do a files only defrag in Defraggler.
    The blocks (clusters) will change colour but will only ocassionaly seem to 'move' as an emptied one turns white or a newly used one turns red/blue. (of course they also turn green/yellow as the data in them is being processed).

     

    I think that this is where the confusion lies. To quote Piriform's Defraggler help pages, 'The blocks in a defrag drive map represent multiple clusters. Each square in the Drive Map represents a section of your hard drive. The size in KB (kilobytes) or MB (megabytes) of the section displayed depends on the size of the drive; the bigger your drive, the larger the storage area represented by each colored square. The order of the squares is the same as the order of sections of your hard drive - the square in the upper-left represents the first section of the drive.'

    The blocks aren't clusters. If they were there would be 240+ million of them for Legendarysnake's 1tb drive. Yes, people like to see the map change colour, we're all children deep down.

     

    3 hours ago, nukecad said:

    But if you want to try and do that and fill up the clusters so that you are using the least number of clusters possible then you have to fragment some files to fill the clusters completely.

    *(That's when the % fragmentation shown by defraggler can sometimes go up following the default defrag; because it's fragmented some files to fill up and consolidate some clusters).

     

    I'm sorry but this is er, complete nonsense.

    All this of course is in offered in the spirit of greater understanding.

     

  2. Nerds' corner here, I'm afraid...

     

    12 hours ago, nukecad said:

    I'm not sure just how much of which Windows 'Defrag & Optimise' does for a HDD these days, but most defragmenters will do a consolidation because that's what most users think defragmenting is.

     

    Do they? I've always thought of defragmentation being an attempt to make all the clusters of a file - the fragments - into one contiguous entity (I almost said consolidate them). I have no idea what everyone else thinks. Do most defraggers do a consolidation?

     

    12 hours ago, nukecad said:

    It is noticable that the Windows 'Defrag & Optimise' no longer shows a drive map, so no longer shows any consolidation happening on HDDs although I'm sure it still does it.

    (If you have an SSD then a drive map is meaningless anyway, so that's one reason they may have stopped showing it).

     

    It's not often appreciated that a defragger doesn't look at the drive to get its drive map. It just - in NTFS's case - looks at the Master File Table. That's the only place where file fragmentation is defined, as the entry for each file holds the cluster runs (one or many) that belong to the file. So the drive map is a mirage.

    The drive map on an SSD would be the same, showing exactly the same fragmentation that would occur if the drive were an HDD. That's because it's NTFS that decides which cluster or group of clusters are to be used by a file, and NTFS doesn't care what the storage device is. Clusters are held as logical block addresses (LBA's), and correspond to physical addresses in an HHD. On an SSD they are mapped onto non-specific page addresses by the Flash Translation Layer in the SSD controller .

    Personally I think that defragmentation is overblown. I have never defragged a disk in over 20 years (apart from a pre-sale cleanup). It might save a few milliseconds but I've just spent zillions of those typing all this.

     

     

  3. Drice Wiper and Wipe Free Space in Options/Settings are separate processes. In Drive Wiper just carry on and wipe whatever you have selected.

    The Options/Settings process is the original method of wiping free space that has been retained. It has fewer options than Drive Wiper and has to be executed by checking Wipe Free Space in Cleaner/Advanced. In  this way it becomes a component of the general 'cleaning' procedure. It is independent of Drive Wiper.

    In Options/Settings the Wipe Cluster Tips and Wipe Alternat Data Streams are part of Secure File Deletion: they are not part of any wipe free space process.

    I don't think this is misleading, but it has caused confusion from time to time.

  4. It's almost impossible to say as there's no picture or information about what settings you're using or what Recuva has found, except for a file count.

    Folder names are held in the MFT, so for DD to find the folder names must mean that the folder structure can be regenerated. What is the Recuva equivalent of the DD screenshot? Does it find a Trash folder and if so what folders are inside it? I assume that Trash folder is a user created folder? Also the number of files in the Trash folder is exactly the same as in the recycle bin, is that a coincidence? And I'm curious why a presumably needed music folder is in your Trash folder.

    By the way the Total, Video and Audio file counts differ for the two runs of DD, so something is happening to the disk.

  5. Nukecad talks sense, although a cavil would be that regarding 'Recuva doesn't know that until it actually tries the recovery', Recuva does't know anything at all, and just recovers whatever clusters are addressed by the deleted files' metadata (not that Recuva can 'know' anything at all). So some recovered data is duplicated.

    Of course we don't know what the O/P is trying to recover. In some cases everything is checked, including Scan for Non Deleted Files, and everything is selected for recovery. This includes system files, some of which are sparse files and have a nominal size of the entire partition, so the space requirements for recovery will exceed the original partition, or drive, by a considerable amount.

  6. Are we discussing the use of Recuva, as in the thread title, or the loss of the c:\users file, as the thread contents seem to imply?

    Deleting the c:\users file is serious. If that is the case then I suggest that you attempt to get your pc back into working order by following this thread

    https://answers.microsoft.com/en-us/windows/forum/all/accidently-deleted-my-users-folder-in-c-drive-on/322fd12b-41a5-4ab9-ba4b-5425520b03ae

    or by typing in deleted users folder in Google, as it is easier to follow those results than for us to try to plough through the process (but if anyone here wants to try then go ahead).

  7. Step back a bit here.

    'I accidently deleted my Users file' - what file (or folder) is that? I doubt if you could delete c:\Users without serious ramifications. Do you mean a folder within c:\users, or a file somewhere else, or what?

    'i'm not able to access the folder anymore' - that's normal when you delete a folder. Do you mean the c:\users folder or the one you deleted or something else? What are you trying to open?

    The thread title is 'Can't access files recovered by recuva'. Have you recovered  53 gb to another drive, and is the folder you're trying to open on that drive?

     

  8. As far as i'm aware there are four timestamps in the MFT file record, File Creation, File Modification, File Accessed and MFT Record Modification. These timestamps are held in the $STANDARD_INFORMATION and $FILE_NAME attributes. Unfortunately none of these timestamps are changed on file deletion, as the MFT record as a whole is flagged as invalid. So a file deletion date would be unavailable. I don't know what EaseUs displays.

  9. It's almost impossible to answer this. We don't know what the file system is or why the card failed, and even if we did it would still be difficult to diagnose. What does Recuva say the file system is?

    From experience most attempts at file recovery from stricken data cards unfortunately end in failure.

  10. Those files pictured are system files which one would expect to see after a disk format. By the looks of the time, nearly five hours, that's a deep scan. I don't know what the 8 ignored files are, possibly zero length or otherwise of no use. As you are showing live files it also looks as if you have that option checked, so there's not much use suggesting that. Unfortunately it does not look as if any other file, deleted or otherwise, can be found. Is the disk an SSD?

  11. 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.

  12. 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.

  13. 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.

  14. £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.

  15. 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.

  16. 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.

  17. 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.

  18. 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.

×
×
  • Create New...

Important Information

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