Jump to content

Augeas

Moderators
  • Posts

    4,542
  • Joined

Posts posted by Augeas

  1. You could try...

    Run CCleaner, leave open after running

    Open Outlook and sign in to your Gmail accounts

    Go back to CC, open Options/Cookies

    Move any cookies associated with Outlook or Gmail to the Cookies to Keep section

    For Gmail on its own I keep accounts.google.com, contacts.google.com, google.com, and mail.google.com - whether I need all of these is debatable but its no great overhead.

  2. You cannot recover data from these files. They are Index files created when a file or folder is sent to the recycler. When a file is sent to the recycler it is renamed to $R followed by a set of random characters, followed by the original file extension, e.g. $Rhdxenv.doc. A matching file is created as $I followed by the same random characters and extension as the $R file. This file contains the original filename/path and file size, and the date and time that the file was moved to the Recycle Bin. When a folder is sent to the recycler it is renamed (as one $I file or two $ files?) in the same pattern as a file but without the extension.

    These $I files look like they belong to a folder, and folders do not contain any user data. I think - and I'm not sure - that files sent to the recycler when a folder is deleted retain their original names, and only the folder is renamed to $I (and $R?).

    I don't think a deep scan would find these files, as they don't have a known file signature in the header (I may be wrong, I haven't tried it). However they are found with a normal scan, and a deep scan runs a normal scan first.

    I would look for files under their original names, which you probably have done so already, or files with names starting with $R, not $I.

  3. NTFS was upgraded to version 3.1 on the introduction of Windows XP in late 2001. I can't see any changes there that would cause problems though.

    A user complained about this with the upgrade to DriveScrubber v14-6, in March 2016.

    https://answers.microsoft.com/en-us/windows/forum/all/i-am-unable-to-use-the-iolo-drivescrubber-software/9c72ea12-351f-465e-9591-0434ada6be20

    I have no idea why this has been postulated, and I can find no other comments about this online.

    As far as I know CC requests NTFS to allocate enough files to fill the volume, and then deletes them, so it is NTFS that is managing the free - and allocated - space on the drive. If Microsoft is using free space to hold data and allowing that space to be allocated to a user file then it's er, suicidal. Iolo's website is particularly unhelpful, so who knows if they are talking sense or not. I would like to know where 'Microsoft warns that there is no safe method for wiping just free space' can be found.

    Of course it could be that the method that DriveScrubber uses to wipe free space was flawed, and they hadn't the resources or inclination to update it, so they chopped it. That gets my bet.

  4. Recuva does not recover folders per se, but it will reconstruct them during a file recovery if the option is selected.

    A deep scan will not reconstruct folders as the folder information is held in the MFT, which a deep scan does not reference.

    Reconstructing folders is possible during a normal scan. To add to the confusion a deep scan runs a normal scan first, so during a deep scan you will see some folders that have been reconstructed: the additional files found by the deep scan - those with no file name - will have no 'owning' folder.

    I wonder if you actually mean recovering a folder? After all you can just create it with Explorer. Is it files you are trying to recover?

     

  5. This is typical of a storage device formatted as FAT32. When files are deleted the first two bytes of the start address are set to zero (by the file system itself). When Recuva, or other recovery software, looks for the deleted files it goes to the wrong address and reports that the file is overwritten by live files.

    There's not a lot you can do. You could try a deep scan but this will not find, or recover, any more than the first extent of a file, so results are limited. But it's worth a go.

  6. Firstly, anything that has been shift/deleted from an SSD has a next to zero chance of being recovered by any recovery software.

    When files are shift/del'd then the file names usually remain accessible in the MFT, as 'flagged as deleted' records, even though the data is unrecoverable. The only reason I can think of off-hand for the file names not being visible is that a number of new file allocations have taken place after the shift/del. This would overwrite (reuse) the flagged as deleted records in the MFT.

  7. No, you should not be running a zero fill on an SSD with TRIM, as it will waste write cycles and achieve nothing. Zero fill was intended for older SSD's.  Windows Optimiser (the new name for Windiws defragger) will keep your SSD in good condition automatically.

    Neither TRIM nor zero fill will speed up your SSD. From my experience SSD's gradually seem to get slower...

     

  8. The problem with trying to diagnose a er.. problem is that we can't see all the data, and we have to make assumptions. We don't know:

    Whether all recovered files, or just some, contain data

    How large these files are, whether they've been overwritten, whether even if they're non-deleted, or what the data is

    How old the SSD is, what quality it is, or whether TRIM is implemented in both O/S and SSD

    Whether the TRIM queue was overwhelmed and some TRIM commands dropped

    Or even if we're talking about Windows and NTFS.

    Assuming that TRIM is implemented, the Windows O/S will issue the TRIM ommand and the SSD controller specifies the action to be taken after a TRIM. Most likely It will be DZAT (Deterministic Zeroes After TRIM). Any read of a deleted and TRIMed SSD page will return zeroes.

    But we don't know what the SSD controller actually does, nor what settings it has, nor how to see those settings. So we guess.

    If I run Recuva on my cheapo SSD and then look at the header info all the deleted files contain zeroes (except for the reasons outlined in my previous post).

     

  9. If files have been deleted from an SSD with TRIM enabled - as you most likely have - then as Nukecad says recovery is nigh on impossible. The file size and cluster information will still be available as this info is held in the MFT and is not destroyed on file deletion. Recuva will follow this info and recover (i.e. copy) the data it finds.

    The return from reading a TRIMed file is zeroes. The exceptions are if the file is very small (under say 700 bytes) and is held entirely in the MFT; or if the file is larger and its clusters have been overwritten by a subsequent live file allocation, when Recuva will be recovering data from that live file.

    Irfanview is good, but I very much doubt it will help here.

  10. I don't wish to steal Nukecad's thunder but...

    Deleted files on an SSD are subject to a TRIM command more or less immediately. This means that the pages containg the file's data are inaccessible by any software. The SSD will return a page of zeroes whenever a read is issued for the deleted file.

    What Recuva is showing is a list of deleted files held in the Master File Table. Recuva will follow the addresses of the deleted file's pages and return those pages during a recovery. The recovered pages will contain zeroes and be of no use.

    Unfortunately there is no way to recover the deleted files once a TRIM command has been issued and executed. This is a property of SSD's and can't be changed after the event.

×
×
  • Create New...

Important Information

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