Augeas
-
Posts
4,542 -
Joined
Posts posted by Augeas
-
-
If the drive is an SSD then you're unlikely to recover any valid data, although what you do recover should contain zeroes not a hex char.
If the O/S is FAT32 then the file cluster addresses are modified on deletion, so that they point to a different, and incorrect, cluster. Recovery is again unlikely.
-
Yes, it all depends on what the OP means. In my experience if Recuva can list a file then it can - in general - recover it. Exceptions (that I can think of) are if the file is zero bytes in length, or the cluster addresses are invalid, or it's a live file that's locked for some reason. In each case there should be an error message. If the recovery is from an SSD then the files can be recovered, but will contain zeroes, which might be what the OP means.
-
Of course the MFT was recreated during the format, that's what a format does. The MFT should contain about 20 or so system files and nothing else.
A deep scan will not return any directory information, as this is held in the MFT. You would be better off running a normal scan with Scan for Non-Deleted Files checked. This is fast and, if successful, will return much of what you want.
-
It's certainly going to make recovery difficult. Did you check Scan for Non-Deleted Files? If so these files - with file names and directory info - will be worthless, as the cluster addresses are multiples of block sizes, the wrong block size. You need to look at the deep scan files, those with just a number and extension.
Assuming the sector alignment is the same (i.e. both block sizes start at the same boundary) then you may possibly find and recover some files. But you will be retrieving two 16k blocks in one 32k read. Whether this is valid, and for all file types, I don't know. Also you will be missing all files that are aligned on the odd-numbered 16k block boundaries. The 32k block reads will read the 0, 2, 4, 6 etc 16k blocks, and miss the 1, 3, 5, 7 blocks. A recovery of a single 32k block will contain another 16K of data. And to add to all that a deep scan will not retrieve anything but the first extent of a file.
So it's all a bit of a mess really. I think your best plan is to quick format back to the old spec and keep your fingers crossed. This time you can check Scan for Non-Deleted Files, and hope that some of the old MFT still remains. But all of this is guesswork, I don't really know what's happened to your disk, it's at your own risk.
-
I don't think that a deep scan will be fruitful as the file extension - unity - is not, as far as I know - one that is interpreted by a deep scan.
Data not found on disk means that the file's data cluster address fields do not contain valid addresses. It is not easy to say why this has happened. It may be because the files were in a lot of extents.
-
More than there are in nothing.
-
You could also try Explorer, right click drive, select Disk Cleanup, Cleanup System Files. Windows Update Cleanup will be first on the list, and if you check that and run Cleanup you should save several gbs.
-
If Recuva shows a list of deleted files that's OK, these are the entries in the Master File Table flagged as deleted. They can't be removed, but will be reused by Windows as and when new files are allocated. The important thing is can you see the deleted data (which will be mostly pics)? If so then TRIM isn't enabled. With an SSD you should not be able to see the data, just zeroes. But as I said this won't affect the free/used space.
Regarding your large files, do you have System Restore switched on? (CC will tell you if you have or not.) The default for Win 10 is off, so that may remove the 15 gb of Sys Vol Info (I don't have such a file). Presumably Mr Gates doesn't think Sys Restore is required any more, and I don't miss it. You might want to consider this, you don't have a lot of free space. I also have a 120 gb SSD C volume by the way, and use 37 gb.
-
TRIM is a process which is enabled by default in both the Op Sys and the SSD itself. It doesn't actually affect the disk space parameters, as that is (probably, possibly?) deduced from the cluster bitmap, and will be the same whether TRIM is enabled or not. Something must be using your space so try Hazlenut's suggestions.
I assume you are right clicking the drive in Explorer and selecting Properties to get the space usage figures?
-
Difficult to say really. I would disconnect from the internet to see if that stabilises things. A CC Analyze will tell you what temp files can be deleted, and if these temp files are huge then before you delete then look at which component holds the huge files, Then post back here.
We are assuming that TRIM is enabled in both the Op Sys and the device? An easy way to check is to run Recuva normal scan on the SSD. If you can see lots of pics and data etc on the deleted files then TRIM is off. If the vast majority of the deleted files are blank/zeroes, then TRIM is on.
-
Recuva recovers the right contents, but not necessarily in the right order (perhaps you need to be old, and English, for that one).
You've been around for too long for me to give you a lecture Willy, but this is too good an opportunity to miss.
Recuva looks at, and displays, the meta data from the MFT during a normal scan. When Recuva recovers a file it follows the data cluster addresses in the MFT and copies whatever is there faithfully. There is no way that Recuva can verify that the data matches the file type, or whether it should, or whether it's what you are looking for. Recuva recovers the data, what you make of it is up to you.
Recovery is a copy operation. Most files can be 'recovered' in this way, even those that have been overwritten. A request for a recovery is a request to copy clusters, and then we're back to the previous paragraph.
-
The ignored files are live files and those which are not selected in Advanced Mode Options/Actions, such as zero byte or system files.
-
I doubt whether anyone is still discussing upgrading a 15+ year old Dell 5150. Indeed, I have one slowly returning to its elemental form in the shed. In the meantime some of us have graduated, married, raised a family, divorced, forged new careers, retired or died, as well as voting out George W Bush and Tony Blair (but not Mr Putin). And bought new kit. This smells of spam (why do spammers pick such old threads?) so your recommendation has gone the way of the 5150.
-
I recommend 'Stop Forum Spam'. You have a bit part in it.
-
Yes, it doesn't look too good. If the file headers aren't there then I doubt if the rest of the file is there either. It's probably due to the formatting with the Win10 upgrade.
I don't know how you managed to retrieve the file names, they should have gone with the formatting too.
The excellent state just says that no other file is overwriting them, not that the file contains any data that is of any use to the user.
-
Is the formatted drive an SSD? If so the files are very likely gone forever.
How did you find the deleted files after a format? The MFT (assuming NTFS) would have been recreated. Did you select Scan for Non-Deleted Files in Options/Actions?
In the Recuva scan (you can run it multiple times with no adverse effects) go into Advanced Mode and look at the file header pane. Is the header all zeroes, or something else?
-
It's true that in Drive Wiper there is no option for selecting a wipe MFT, but that's because you get it anyway as a freebie. If Drive Wiper WFS is run you will see a Wiping MFT message at the start of the run. It could be argued that a WMFT is part of WFS, as some file data is held in the MFT record and is not wiped by a 'normal' WFS.
As far as I know the WFS parameters in Options/Settings have no effect on Drive Wiper.
The Wipe Alternate Data Streams and Wipe Cluster Tips are settings for Secure File Deletion, which is not part of Wipe Free Space.
I think that the reason why WFS is still available in CClean is that it could be incorporated in the users CClean runs, whilst Drive Wiper is a stand-alone operation. I suppose there are some users who would want that, although it seems rather excessive.
I have to say that I've never run a Wipe MFT in my life, and only run WFS when I was getting rid of my old kit.
-
To clarify a little, as I understand it Nukecad, WFS in Drive Wiper runs a wipe MFT before the disk wipe. Unless things are different in Custom Clean, but I never run any WFS to test it.
-
In the first example the file's data is held in a separate cluster. In the second the data is held entirely within the MFT record for the file. The cluster can be overwritten by another file allocation, but the MFT record can't be overwritten until that record is reused.
I don't know, of course, what has happened to the data cluster. It could have been reused by a temp file (internet search etc) which has been subsequently deleted. In any event the old data has almost certainly gone.
-
I never knew there was such a word as Drobo until I saw this thread.
Recuva gets its information from the MFT - this holds the file names etc and the data cluster addresses. Recuva will copy what's at those addresses (the data within the clusters) when it does a recovery. It's a copy of what's there, there's no concept of the data being good or bad. If the headers are zero then it's likely that the rest of the file is zero, and thus, from a user point of view, unrecoverable.
From NTFS's point of view there's no reason why the data should be zeroed, data clusters are not touched on file deletion. However the Drobo is some variant of Raid, and I think there's a SSD front end, so I have no idea what's going on inside the box.
If you want you could download the portable version of HxD hex editor and use it to look at the recovered files one at a time. You can skim down through them and see if they are all zeroes, as I suspect they are. If so the file data is lost. I don't think a Recuva deep scan will help in these circumstances.
BUt I'm no Drobo expert, perhaps a data recovery firm could advise.
-
Are the drives in the Drobo SSD's?
Have a look at the header info in Recuva Advanced mode. Are the headers all zeroes, or random data, or what?
What file system is the Drobo?
How large are the video files?
This might be interesting.... https://recoverit.wondershare.com/repair-video-file/how-to-repair-mp4-video-header.html
-
CC saying an HDD as an SSD is an error. I don't know how CC identifies a drive, whether it interprets the model type or uses some other method, but sometimes it goes awry.
However (and many others will tell you this) you don't need to do multiple passes on an HDD overwrite, one will do. No commercial organisation in the world claims it can recover once-overwritten data, and if you're worried that MI5 might be bashing in your door then I respectfully advise you to surrender to the authorities.
-
Drive Wiper runs a wipe MFT before a WFS, in as much as it overwrites the file names and data in the MFT. The total number of deleted files in the MFT remains the same, but the file names and data have gone. WFS in Options has no affect on Drive Wiper settings, and Secure Erase has no effect on WFS at all. So stick to Drive Wiper.
I don't know what Disk Drill is returning (and I don't really want to know). I know that once CC Drive Wiper has overwritten the free space (and it does a preety good job at that) then that overwritten data can't be recovered by any means. Maybe DD is returning deleted file names (which should be ZZ.ZZ after running Drive Wiper) or maybe it is returning live files, but it cannot, under any circumstances, return any data that was there before being overwritten.
-
It's difficult to give an answer without more details so we can only generalise. Did you use CC's Drive Wiper or WFS from Options/Settings?
First of all Wipe Free Space is an overwrite operation, it does not explicitly remove anything. A WFS works by filling a volume's unallocated space with files holding zeroes and then deleting them, thus overwriting the data in free space.
NTFS volumes have a Master File Table which holds a record for every file on the volume. These records are flagged when a file is deleted, and subsequently can be reused, but they are never removed from the MFT. A WFS may - depending on the settings - overwrite the file names in the MFT's records. After a WFS Recuva will still list all these deleted records, with file names which may be valid or not, and these files can be recovered (in as much as the file's overwritten data can be retrieved). But they will either be all zeroes or small zero files. In other words no use to anyone.
I have no experience with Eraser, BCWipe or Disk Drill so I don't know what they are showing. I would say though that CC WFS does overwrite the vast majority of free space, and when that is done, with one pass, that data is not recoverable by any means known or available to the hoi polloi.
Don't run WFS on SSD's. If they are reasonably modern with TRIM enabled then all unallocated clusters will return zeroes.
"it appears that we don't support this file format" problem
in Recuva
Posted
It's (probably) due to the way the SSD controller handles deletes, NAND flash architecture, and Windows TRIM for a start. When a page is deleted TRIM notifies the controller and the controller unmaps the page. Any reads of that page, as Recuva will do when if follows the cluster run addresses held in the MFT, will return a default page, commonly of zeroes or less commonly random data. Look up DZAT and DRAT on Google.
In the real world deleted data on an SSD has gone forever. The unmapped page is in limbo, and is wiped, sooner or later, by the SSD Garbage Collection process. Perhaps, just perhaps, a data recovery firm could recover some data, but I imagine it is an expensive process, if possible at all.
I don't believe there's any way that Recuva could retrieve deleted data from an SSD with TRIM enabled. It has physically gone.