Augeas
-
Posts
4,542 -
Joined
Posts posted by Augeas
-
-
Ignore the fact that it says unrecoverable. Can you see the pics in thumbnail view? If so, recover them. You could also try the Deep Scan and Scan for Non-Deleted Files options: I don't know if they are relevant to an SD card, but it's worth a try.
-
Possibly Filename means that he/she used secure delete to overwrite jpgs and some can stiil be shown using Recuva. They could be copies created during file move/edit/copy/resize/etc operations, which CC will not see or delete. Recuva can overwrite these files.
-
I'm sure you're right, but puzzled about specifics.
Where did you get the info?...From the docs (http://docs.piriform.com/recuva/using-recuva/advanced-mode/recovering-deleted-emails) and from previous posts in the forum.
-
Another search of the forum and the web would reveal that there's a great deal of discussion about whether any data can be, or has ever been, recovered after a single overwrite. No evidence appears to exist that it has.
As for wearing out the disk, the heads should not be touching the platters, so any additional wear would be in the arm actuating mechanism. More arm wagging would shorten the ultimate life of the mechanism, but by how much? The disk will probably still be going at the end of the pc's 3 to 5 year life.
-
At some point a user of your pc (or that hard drive) browsed web pages that contained those pics. If the pics are large then they were probably downloaded.
Assuming you have not ticked the Scan for Non-Deleted Files option then everything that Recuva returns has been deleted and is not taking usable space from you. If you want to get rid of these pics then tick the checkbox alongside them, right click and select Secure Overwrite Checked. You can do whole blocks if you wish, or even the whole list if you tick the top l/h box (but that will overwrite everything).
The only way to scan for your own pics is to look through what Recuva has returned.
If you chose the option Deep Scan Recuva will return (eventually) far more files, and possibly far more rude pics. You can overwrite these in the same way as described above. You might also find some of your pics there (not amongst the rude pics, but in the deep scan).
-
I'm sure nobody will criticise you Willy. I could do with a few braincells being stimulated.
The two Include options (select Folder or File) are not dependant, if you select either one then anything selected in the other is removed. Maybe it was done this way so that there was no confusion with the File Types and Options boxes, which only apply to folders and are deselected if File is chosen. I can't see any confusion as it is, choose either a folder or a file. As Aleksandr Orlov would say, seeemple!
-
Resolved in V2.30, is it not?
-
Going back to 2.28 wouldn't prove it for me, for reasons in my previous post. If you add a folder to the Include list, there is a message saying that 'This folder will be emptied of all files upon cleaning', which implies that the folder itself would not be deleted.
Although I'm on XPSP3 I can't see it being an O/S issue. Perhaps a Cleaner.ini clash? (I don't use C.ini).
-
As far as I know (and what do I know?) the included folder name has never been deleted whatever version of CC is used. I have a My Documents/Crap folder into which I throw er, crap: this folder is in the Include list and has never been deleted. But all of its contents, including subfolders, have. In the latest version of CC I had to tick the Recurse subfolders box, but otherwise it's the same old stuff.
I would also add that in my opinion the named folder should not be deleted by default, but there should be an option to do this if required.
-
To disappointed deleters, I don't know what the specific problems are, but Recuva will not delete:
Files shown when the Scan for Non-Deleted Files option is ticked
Files of zero length
Files which are contained entirely within the MFT (less than 1k)
Files which have been overwritten by another file creation
And probably a few more I can't think of.
-
No secret. It's a logical entity, and indicates that there are deleted emails that could be recovered, if you so wish. The zip file is only created when you issue the recover command. So it cannot be securely deleted as it doesn't exist.
-
Is it something.or.other.emails.zip, Meadows?
-
Everytime CC scans a drive/drives for files to be wiped it reads a lot of and perhaps all directory files on one or more drives. And then, without a shadow of doubt, it comes across (a lot of) files that are simply marked ""deleted"" but have not been ""wiped"". When a user has enabled the ""Secure file deletion (slower)"" option or the WFS option then an additional option could order CC to ""wipe"" all these files, who were marked as ""deleted"", as well, on every drive CC has scanned. The advantage of this is that this thorough cleaning prevents the MFT from growing too much and occupying a lot of/too much diskspace.
I'm a little confused. Are we still talking about wiping the MFT records or 'files', i.e. the clusters associated with the MFT entry? I'll assume MFT and files. How would wiping either the MFT or files prevent the MFT from increasing in size? How would anything, apart from a disk reformat, prevent the MFT from growing?
As for the clusters that a deleted MFT record points to, I would guess that NTFS obtains a lock on the next available free record in the MFT, then uses whatever algorithm is necessary (depending on head position, file size etc) to find available space, writes the file, and updates the MFT. The cluster addresses in deleted MFT records are irrelevant, as shown when Recuva frequently finds overwritten clusters.
-
No, I don't run either WFS or WMFT, and probably won't unless circumstances force me to, but I am interested in the technical side of it. On the other hand I don't run the country either, but I offer that nice Mr Brown plenty of advice. And threads like this give me an excuse to pontificate at length.
As we well know you can only write data to drives, not wipe or erase or delete or clean or any other word that makes you feel all warm and comfortable. So to wipe etc. you can only write, or overwrite. I've looked at a few disk wipers, and the general method seems to be to allocate files until the disk is full, forcing data into the MFT zone (in XP). Then zero length files are allocated until the MFT is full. Then the lot is deleted. There's no published information on the workings of Piriform products, so we have to assume that the WFS and WMFT processes in CC use a similar method to other commercial wipers.
The MFT can be wiped (now I'm using that silly word) on its own. You can even do it manually. and you do it in part every time you use your pc. All it needs is enough new files to be created to overwrite all the 'spare' entries, those from previously deleted files and directories. The number of spare entries is available from Windows defragger analysis, or Recuva, or other means. Possibly CC requests or calculates the number of free entries then runs an appropriate file create/delete process.
To run a selective MFT record overwrite is another matter. Perhaps internally to NTFS there is a Next Available Record function, so you could see which record is about to be reused. Fine, except that the record the user would like to be wiped is most likely not the next available. So how would an application position itself on the desired record, and how would it force NTFS to use it? I think that there are three reasons why selective MFT record wiping is at least not practicable. Recuva doesn't do it. Other disk wipers, more sophisticated than Recuva or CC, don't do it. And it just doesn't have any real point or purpose.
As all records in the MFT are a collection of what NTFS calls attributes, there would never be a way that any application could tell that an entry had been 'wiped'. Wiping is replacing one set of attributes with another - there's no such concept as a wiped attribute. Why should an application use complex code to check whether the attributes are shall we say 'safe' when it's easier, faster and less prone to error to just overwrite it, as it does with all the others? If Piriform even thinks about implementing selective MFT overwriting I'll eat my hat.
I wouldn't put too much faith in a progress bar indicating where the deleted records are held. With a constant file creation and deletion process in normal pc usage they are bound to be fairly widely distributed.
That's enough for today.
-
Agggggghhhhhhhh!
1) Personally I don't think you'll get that. Cancel is cancel. You will have more chance asking for the WMFT to be a separate operation.
2) As far as I (and a few others) know the WMFT process is to create a number of small (600 byte?) files sufficient to use all the available deleted entries in the MFT, and then delete them. This doesn't allow for selective overwriting, as NTFS will decide which MFT entry gets used in new file creation.
3) You can't, for reasons in answer 2. Windows doesn't allow applications to poke around in the MFT, you have to ask it nicely.
-
Although Recuva is probably telling the truth try viewing the scan in thumbnails, you may see some recoverable pics there. If so recover them to a separate drive.
You cold also try a deep scan, and view the much greater list again in thumbnails.
The real test of whether a file can be recovered and opened is to do just that.
-
I guess the only danger is that chopping the WFS option might leave one or more of the filler files that CC uses to overwrite free space in the root directory. Perhaps CC clears them up if you press Cancel, as opposed to a brute chop.
-
Hi Meadows, I was curious to know what advantage there was in overwriting the MFT before overwriting free space, as opposed to overwriting free space first and then the MFT.
This thread http://forum.piriform.com/index.php?showtopic=27221&hl= indicates that it is not possible to overwrite the MFT without overwriting free space. So how are you overwriting the MFT on its own? When you overwrite the MFT what indication is there that this has indeed been done?
P.S. Just seen your PS. That explains how you do it (but 20 days after the thread started!). I can't see any great danger. What happens to the deleted file names in the MFT after running Wipe MFT this way?
-
Thanks JD, That's a great step forward. I am obviously too chicken to try it myself. Don't superheroes ever sleep?
-
Hi Willy,
I only know about the MFT from reading various technical articles on the net.
I'm not sure what you mean about the directory file. As far as I know directory entries are held in the MFT along with other file entries. And I'm still not sure what your concern is with zero length files. CC will treat them in the same way as other files: when secure delete is enabled the entry in the MFT is overwritten. All files, and directory names, are overwritten with secure delete.
However the Secure Delete and WFS options are separate: the secure delete overwrite methods apply to files only, not to WFS.
I don't think that the documentation specifically says that WFS and WMFT can be run separately, although it is a little ambiguous. All it says is that if you choose both WFS and WMFT, the WMFT will run first. If you could overwrite the MFT separately, why isn't WMFT a separate entry, as you say above? And if WMFT is separate, how do multi-partition/drive systems determine which MFT to wipe? Furthermore, how would you enable WMFT, as there isn't (as you also point out) an entry on the main page.
As it seems that you are keen to use WFS and WMFT why don't you run a WMFT on it's own, with nothing ticked in the WFS box and without ticking the Wipe Free Space box on the main page? I bet that nothing will happen.
-
When running CC with secure deletion enabled zero length files do have the entries in the MFT overwritten. WFS with the Wipe MFT option enabled should do the same thing: rather like a morning after pill following an evening of dissolute surfing.
-
You can't physically overwrite zero length files. Perhaps you mean the filename info in the MFT?
As far as I can deduce, the wipe MFT option requires wipe free space to be enabled as well. My deductions are that without WFS being ticked there would be no indication of which drive the WMFT is to be run, and there's no separate option in Cleaner to initiate WMFT, as there is with WFS. But I could be wrong. I don't use either option, and those who do seem quite relectant to say what actually happens.
-
It would appear that recovering to the same drive has overwritten just about everything that your client was attempting to recover. There is no software available that will recover data that has been overwritten. There will be a few scattered remains of the 45k files that will be good (I wouldn't imagine that the recover process writes in a one-to-one correspondence) but they might be tricky to find. You'll need to page through all the recovered files in thumbnails mode to see.
-
Certainly pulling the disk and running it as a slave data-only disk on another system will reduce the chances of anything being overwritten.
I assume you ran the recovery to another disk/partition? Although normal pc use will tend to overwrite some deleted data, losing 45k files is rather a lot. There hasn't ben a defrag or anything else major on this disk?
By all means try Spinrite - I have no knowledge of this at all but anything non-invasive is worth a try.
Where did you get the info?...
some jpg image files won't clean!
in CCleaner
Posted
Have you tried CClreaner's Wipe Free Space/Wipe MFT?