Jump to content

Augeas

Moderators
  • Posts

    4,542
  • Joined

Posts posted by Augeas

  1. From what I can deduce..

     

    You created a doc file, deleted it to the recycler, then cleared out the recycler, then ran Recuva and recovered the doc file.

     

    You then ran CC, then ran Recuva and couldn't find the deleted doc file?

     

    It is common if you delete a newly created file for it to be 'lost' quite quickly. This is because the file, or its entry in the MFT, is first in line to be reused by another file creation. Whilst the user may not have created any new files, Windows quite happily does. It could be a prefetch entry, or a temp file used by any of the applications running, an email or a/v file, or anything really. Deleted files are constantly at risk from being overwritten, and that's probably what's happened in your case. Conversly, older files are less likely to get the chop immediately.

  2. Everything that Marmite said. The last thing that CC needs is another secure deletion method.

     

    I had a scratch around at Bruce's method. He proposed this in 1996 (the same year as Gutmann), and gave no rationale apart from being paranoid and believing that the more overwrites the better. I believe he actually said using a 'cryptographically secure pseudo-random sequence': a random number generator would be nonsense, wouldn't it?

     

    The whole concept is just wrong anyway. If you want to ensure that your data is eliminated to any sort of verifiable standard you wouldn't use a free general-purpose utility. I think CC is great, but I wouldn't dream of suggesting it should be used to clean data to any auditable standard. If anyone ever asked me, that is.

  3. Ah but you can. Add your directory as usual, so that c:\directory\stuff\*.* is in the Include list. Right click on the folder name you've added and select Manual Edit. Edit the extension to c:\directory\stuff\*.xml and save. Go to Cleaner and right click on Custom Files and Folders, and select Analyse. See what's listed, and if it's what you want.

     

    Test this first. I give no guarantees.

  4. I'm not sure of the viability of saving a current scan, either in part or whole. A scan is a snapshot, and a later scan would of course return a different set of results. A saved scan would decay as time passes. I don't know what further info Recuva extracts apart from the displayed list, I wouldn't be surprised if there were some location info stored as well. It would be more complicated with a deep scan, which is more likely to be saved due to the time taken.

     

    You can of course use a filter already, in the path/file name box. Recuva will still do a full scan though, and just filter the display.

     

    My stage 1 scan takes about three seconds, I always cancel stage 2. An option not to run stage 2 would be handy!

  5. I think that Layout.ini is created from info held in the other prefetch files. If you delete it then Hey Presto it pops back up again exactly the same as it was before, with all the same dross in. I believe that each pf file has a list of last looked at or loaded files, and Layout.ini acccumulates all these files in its enormous list. Prefetch then runs a defrag of the files in the list every few days, another reason for keeping a tight prefetch list.

  6. I know from experience (I have the prefetch option ticked) that entries 14 days old are deleted. In my case that's a benefit, as I never reach the prefetch entry count for Windows to clean it up (which is I think around 136). I have around 60 or 70 entries so the old stuff would never be cleared, so CC does it for me.

     

    The thing I dislike about prefetch - and I believe the advantages are such that it should be enabled - is that it catches a lot of dross. Just look at Layout.ini and see what it includes in its auto-defrag and loadup routines: temp int files, sys restore, lang files i shall never use etc.

  7. it does not take more than 20 minuets on a 180Gb drive.

    Then you certainly ain't overwriting 35 times. If you were you'd be creating and writing 6.3 terabytes, and you won't do that in 20 mins. Even if only half of your disk is 'free' you would have to write well over 3 terabytes, and the same applies.

  8. No logs, but you can run an Analyse and then right clck on the display panel and select Save to Text File. You can expand the list as well by right clicking and selecting View Detailed Results.

  9. First of all approx how much data was deleted from the recycler? Pics and vids are large. Secondly, how long did it take to delete them? Wiping a large amount of data 35 times takes time, so if the deletion went through in a few secs it's unlikey that they were overwritten.

     

    Thirdly what are the properties of the deleted files (look at Info using Recuva)? Do the dates, folders and times match what you expect? If not they may be older copies from edits or other activity.

     

    Fourthly do a controlled test with one newly named file, not necessarily large, and see if you can reproduce the problem. Run a CC analyse before the deletion to see if the file has been selected for deletion. Delete it and see what CC says regarding data deleted. run Recuva to see if you can recover it.

     

    PS Files deleted from the recycler should be renamed by Windows. Files deleted by CC secure overwrite will be renamed zzzz.zzz. Did you find your files under the original names?

  10. There is no concept of 'Not permanently' overwriting data. Nothing that has been overwritten, even once, can be recovered in its original state. CC tells the disk controller to write zeroes (or whatever) and it is written. If Recuva recovers that file it will recover zeroes. The disk controller must return what was last written to disk, not what was once there several writes ago, otherwise your pc would be junk.

     

    If Recuva recovers data you think has been overwritten, then either the data wasn't overwritten in the first place or another copy has been picked up.

     

    CC is, of course, primarily a junk clearer-outer, not a forensic data eraser, so some fuzziness to accommodate speed and ease of use is to be expected. Even if it did overwrite all that you asked it to do there would still be many dark corners of Windows holding your secrets.

  11. Don't stop me now - a normal scan will look at and display the file names from the deleted file entries in the MFT. Only the MFT is scanned, nothing else on the hard drive.

     

    A deep scan will do the MFT part and also scan all the used clusters on the hard drive, and return the file names it finds in these clusters. I am not fully aware of the technique Recuva uses to either find or extract filenames from these clusters, presumably it looks for some known header info in each cluster and extracts the name there. I also don't know what it does if it finds a cluster with random data. I think there are files found called ? so these may be them, or they.

     

    A deep scan will return far more hits than the normal scan, and take far longer to run. My normal scan is around 1,600 hits, and deep scan around 70,000 hits. I'm sure others have far more as I am not a heavy pc user. Far too many books to read.

     

    (All subject, of course, to correction or ridicule from the Piriform chaps, who do know what their software does.)

  12. Well, sort of. As far as file names are concerned, these are held in the MFT. When a file is deleted its entry in the MFT is flagged as deleted but remains (the MFT never reduces in size). When a new file is created a deleted entry is used to store the new file name and the old name is completely removed. So the amount of deleted file entries in the MFT varies minute by minute as you use your pc, and hour by hour as Windows creates/deletes sys restore points, updates the prefetch list, applies sys updates etc, and your antivirus updates its data base.

     

    If you maintain your system with CC, for instance, then you will probably never have a 'full' MFT, there will be enough deleted entries available for reuse. Some deleted entries might possibly miss the reuse bandwagon, being in some remote corner of the MFT, and never get overwritten. This is no problem. However a good Windows update should catch most of these, I recently had a spare list of three entries after a Windows update (followed by an immediate CC run to get back some more slack).

     

    As for the actual file data on the drive, the same principle applies more or less. Old data will be overwritten, but inevitably there will be more scope for the data to be spread more widely, and there is no obligation on the O/S to overwrite old data, new data can be written anywhere. I imagine that due to the O/S trying to keep access time to a minimum most data will be written in the same area, not out on the end of the drive, so most data will get overwritten. Conversely, data that is out of the way somewhere will tend to miss the overwrite process and remain forever.

     

    A Recuva deep scan will show what data is out there on your disk, and a CC wipe free space should overwrite it. Personally I've only run deep scan twice in my life, and wipe free space never. I'd sooner read a good book.

  13. You can't 'recover' anything that's really been overwritten, but there may be hope. NTFS is quite picky about not losing data, so the copy over to your hard drive may have been a write copy to new space, check OK, change file address to point to new copy, leaving the old (but desired copy) on the disk. Also your editing process may well have saved some copies as it went along.

     

    If you haven't installed Recuva then download the portable version to the flash drive and extract and run it, scanning the hard drive. If you find anything of the same name and date, recover it to the flash drive and look at it. This would be the best scenario.

     

    Second best scenario (i.e. first sc.. failed) is to do a Recuva deep scan. This will take far longer and return far more files, which can of course be sorted by filename.

     

    Worst scenario (i.e. 1 and 2 failed) is that your pc use has already overwritten any copies you had, or might have had. Redo your work.

     

    It depends what you mean by recently. If it doesn't mean 'a few hours ago' (it usually doesn't) and you've been using your pc, as is most likely, then chances are slim.

  14. Yeah, I get this too. There's stuff from yesterday's browsing (no CC use) and I'm sure I never get anywhere near my cache limits. I don't know if the browser auto-dumps this temp rubbish, it certainly appears to.

     

    The most irritating is the BBC. I always end up with pics of those pompous, self-important, supercilious, smug and insuufferable z-list celebrity cooks sniggering at me. I have to secure overwrite those.

  15. After running WFS you will still be able to see some deleted file names if you run an application such as Recuva. These file names are held in the Master File Table which WFS does not touch. Recuva may show a few thousand file names, whilst WFS has probably overwritten many tens of thousands of files.

     

    The majority of the deleted file names in the MFT will be overwritten with continued pc use, as new files are created. And new deleted file names will appear, in a rolling process (if that makes sense).

  16. I'm not really sure what you're saying. Yes, to recover all the data to another drive would require you to obtain another drive of sufficient size to take the data. Are you saying that can you recover some data to the same drive, then more etc? Not if you wish to recover a reasonable amount of data.

     

    If Recuva recovers data to the same disk it will write to wherever free space is available. Sooner or later (sooner, if the disk is reasonably full) the data will overwrite other deleted data waiting to be recovered. From then on your chances of finding data to be recovered will diminish.

     

    You could recover some data to a smaller sized external disk, hive it off somewhere and then recover some more, if that's what you mean.

×
×
  • Create New...

Important Information

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