Jump to content

Augeas

Moderators
  • Posts

    4,542
  • Joined

Everything posted by Augeas

  1. As we don't know what the 'different overwriting program' was (and don't tell me, I will know nothing about it) we'll have to assume that the process was similar to CC's, i.e. that the file is edited to contain only zeroes then it is deleted. It's a bit of a misnomer, there is no such thing as secure deletion, it's an edit then delete. The MFT record for a file contains a header then a string of variable length attributes, beginning with $Standard Info, then $File Name. etc. Attribute $Data holds the addresses of each data fragment as a cluster start number and cluster count. If there are many fragments then the addresses can't all fit into the 1024 byte record, so a new MFT record is created containing just the $Data attribute, and the main MFT record points to that. (These cluster addresses are often held as negative little-endian, which is not to be trifled with, but I digress.) When a file with a large number of fragments (and multiple MFT records) is deleted then NTFS overwrites the cluster addresses in the extension records and overwrites the link to the extension records in the main MFT record. I've no idea why NTFS does this, it probably values MFT integrity over assistance in recovering deleted files. So you are left with an MFT record (which Recuva finds) with a file size of 1.2 gb in the $File Name attribute and no accessible data clusters. I have seen Recuva issuing the data not on disk message in similar cases. I haven't tried to overwrite one of these records but I would not be surprised if Recuva says that the data is resident in the record (which as sure as grass is green it isn't), as there are no data clusters to locate and overwrite. I am coming (OK, I'm already there) to the conclusion that your 1.2 gb file was in many fragments and the above scenario applied. It's not much to worry about (but why were you tryimg to recover a securely deleted file?). If the file had been normal deleted then a wipe free space would be required to overwrite it.
  2. The really foolish thing is that Analyse gives the results in the old 'advanced' mode, everything set out just as you want it. Then Run Cleaner switches to baby mode, so there is no immediate comparison to the analysis unless you faff around switching modes. There's no right click in baby mode either. I suppose I'll have to get used to it, but I'm not impressed with a picture of the Invisible Man and a coffee cup with a piece of paper in it.
  3. Perhaps a dictionary is the best place for the answer. I assume that English is not your first language, I'm pretty sure you're not Guillermo Eiland the actor, and I'm certain you don't come from California. Your posts here and on many other forums tend to be a little spammy, maybe some offline study would be a help.
  4. Augeas

    INFO Needed

    Options? If you had gone into Drive Wiper and opened the drop-down box you would have had the answer hours ago. The options are, in order of idiocy, 1, 3, 7 and 35 passes. I've no idea what HIPPA complaint (or compliance?) is. There is no compliance with anything with CC. It has no verification and no certification, so probably doesn't conform to any 'official' procedure.
  5. Ultimately it is your choice.
  6. If it's two months since deletopn, on the system drive, and there's a million images, I tink that there will be very little chance that you will recover a substantial amount of those images. And if you did then identifying and reinstating the others would be a horrendous task. I would reinatall.
  7. No, but if you run a normal scan (with select non-deleted files) and no deep scan the scan will be complete in a very short time. You will still get all the deleted files from the MFT, but you will have to manage this.
  8. Just to clarify, a deep scan runs a normal scan first so there will be files listed with file and folder names. Everything before the first [00001].ext file is from the normal scan. The normal scan takes info from the MFT. Each folder has an record in the MFT, that's the only place where they exist. Folders with a ? in the name mean that the record for the (deleted) folder has been reused, so the MFT record for the file is unable to chain back to the root.
  9. Well, that must be a relief. You have to be adnired for sticking at it. Files found with a deep scan (those with [01234].ext name) can't be ordered by folder structure as that info is held in the MFT, which the deep scan bypasses. Good luck with the sort.
  10. You certainly get the prize for perseverance.
  11. This is phemonenally long for (I have to disagree with Nergal) what is nowdays such a small drive. I have a 256 gb drive with 80+ gb free and a very old PC and a deep scan takes about 40 minutes. So a 500 gb drive should take - lets be very generous - three hours or so. The USB connection will probably slow the process down, but I don't know by how much. Not six days, that's taking the micky. I don't know what Recuva is doing internally, it should be reading each unused cluster and searching for a recognisable file header, then building some sort of tables in memory. That's not too onerous. It seems that for some drives, or some conditions of a drive, it gets into a loop. Can it really do mass multiple reads on many clusters before moving on? Maybe, but six days?
  12. I am now seeing the slim version (along with the installer and portable) on the builds page via both the http and https urls. Hopefully this has now been resolved. But it begs the question posited by the O/P in this thread, why is the builds page effectively hidden, as there is no link to it from Piriform's site?
  13. H, yes, on first try the direct link to the slim version opened a pure white page and a separate download box (don't know what the tech name is for them) for the slim version. Now all I get is a blank page.
  14. The builds page opens but does not show the slim version. When I first tried the direct link to the slim version 30 mins ago a blank page opened along with a download box which seemed to be fine. Now when I try it again all I get is a blank page.
  15. Well, I've refreshed (ctl-F5) the builds page, run CC, restarted my pc, turned Defender off and on, and still no slim version in sight.
  16. Win 8, FireFox Quantum 58.0.2, Windows Defender.
  17. Good Heavens no. Do you see the slim version on the builds page?
  18. I've just tried my link again as in post 4 and it works fine. If the download is location or virus checker dependent then why did I download it OK, then not OK, then OK again?
  19. Recuva recovers files to wherever you specify. It will not replace them where they were. They should be recovered to a separate folder on a different drive from the source drive.
  20. That's strange. It quite quickly diverts to https://www.ccleaner.com/ now, but it didn't when I posted the above. I downloaded the slim version quite easily. In fact I played with the url and replaced slim with portable, and that worked and still works (but for how long, I wonder?). I also wonder if someone is working late at Piriform. These url's are timing out now. I don't know what's going on. I just wish Piriform would say what they're doing and put an end to all this nonsense.
  21. Try https://www.ccleaner.com/ccleaner/download/slim
  22. Yes, encrypt the file. There are plenty of free encryption applications available. I use TrueCrypt for my password file, which - despite it's abandonment by the developers recently - is still uncrackable by any normal means and is easy to use. Easier than all this copying, editing, printing, writing to dvd, deleting, wiping free space, and you're still ending up with a printed copy, the most insecure security.
  23. Files can't be renamed before recovery. Just reciover them to a new separate folder on a different device, and all will be safe. You can then rename them to your heart's content.
  24. It's difficult to see how that occurs. A deep scan will look at deleted clusters until a known file signature is found, then recover the following clusters until another file signature, or a live file, or some end of file indicator, is found. In theory there's no way a sequence of clusters greater than the free space on the disk can be requested. So if that's the message you're getting then I'm out of ideas.
×
×
  • Create New...

Important Information

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