Jump to content

Augeas

Moderators
  • Posts

    4,542
  • Joined

Reputation

2 Neutral

About Augeas

Profile Information

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

Recent Profile Visitors

33,004 profile views
  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. Is the drive formatted as FAT32?
  4. The old question is, is your drive an SSD? The state of Excellent means that no data clusters have been overwritten - yet. Whether the contents of those data clusters is what you want is another matter (which is perhaps just a rephrasing of what Nukecad said).
  5. 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.
  6. 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?
  7. 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.
  8. Augeas

    Not Overwriting

    Is this anything to do with your previous post seven years ago, which was itself a response to the same problem in 2009?
  9. ZZzz files are usually caused by running secure delete. I assume that this applies to securely deleted folders as well. Wipe Free Space folders seem to have random names.
  10. Yes, recovery from an SSD is just about impossible, there's plenty of info on this forum as to why.
  11. The usual question ihn these cases is was the storage device an SSD. so I'll ask it.
  12. 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.
  13. It looks like the file system is ext4, which I am told is a Linux f/s, mounted on a Win 10 system. What the relevance of this is I don't know, but it doesn't look like a happy device.
  14. Is the original device (from which the files were deleted) an SSD?
×
×
  • Create New...

Important Information

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