Augeas
-
Posts
4,542 -
Joined
Posts posted by Augeas
-
-
I don't know what caused your problem, some minor file corruption maybe. but I would advise that you use one pass secure deletion instead of Gutmann, or even better just good old normal file deletion. Gutmanning a 5 gb file - if done properly - will result in onver 175 gb of data to be written to the disk, and possibly quite a lot more. Apart from the time taken, it gains nothing over one pass.
Was your bad file named $Rxxxxxx? Windows renames files sent to the recycler to this format, along with a matching $Ixxxxxx.
-
You're right, Henriette, the slim version is 1223. I assumed that as it was the same name and size as the old version it hadn't changed.
Anyway, I'm now on 1223 on my XPSP3 machine. All restore points are shown, WFS isn't ticked. There is no noticable difference.
-
It's the German rate of VAT, where payment - for some reason - is made.
-
It has been commented before that running WFS will remove system restore points. That appears to be the way Windows works when a disk approaches full capacity (WFS fills the disk with large files). Microsoft state ( http://support.microsoft.com/kb/301224 ) that
'The deletion of restore points may be caused by ... the following by-design conditions:
You run out of disk space on the system drive or on any one of the available non-system drives, and System Restore stops responding and stops monitoring your system.
This behavior causes the system to delete all restore points in an attempt to free up disk space. However, you have probably already received a warning about running low in disk space prior to this point.'
This doesn't explain Ishan and Dave D's problem, that they lose the sys rest display in CC and don't use WFS (you could hardly run it by accident without noticing, could you?). I'm still seeing all mine but I don't run WFS and the latest version of CC hasn't been propogated to the slim version, so I'm not on 1223.
-
Not that I know. In any event you would have to store more than is displayed, cluster location for instance, so that CC could identify the cluster(s) holding the deleted files, there being no file table to look up. I suppose it could be done, but all the info that CC needs at the moment to reference the files would have to be saved, and I don't know what that is. It would be a large file, and would decay quite quickly with hd usage.
-
Coinshooter, you asked this question a month ago with no resolution. I can only suggest using some brute force methods. Try renaming and/or moving your music folders to see if that keeps them safe. Or just back them up somewhere and let secure delete take its course. If something like that was happening to me then securing the data would be the first thing I'd do.
-
I've moved this to Recuva Bugs so that Piriform devs have a better chance of picking it up. It looks - to my poor eyes - that perhaps the dynamic tables Recuva builds are overwhelming memory when scanning a 1 tb drive. But why the normal scan fails I've no idea. Perhaps posting some O/S specs etc would help. How many files are found when the scan is cancelled at 800 mb?
-
Does this happen on all files, or just some files? What is the message Recuva returns?
-
What do you suggest would be suitable?
-
Yes, thanks everyone, comments much appreciated.
-
Possibly because you have the Option 'Scan for Non-Deleted Files' checked. This will give the symptoms you describe. Uncheck it and all will be well.
-
Running WFS on occasion will not cause any harm. It is seen as causing some wear on your hard drive, but if you only run it now and again it shouldn't be a problem (I have never run WFS on a hd, only on a flash to see what it does).
1st computer: Files with ZZ names are usually produced by running secure delete, not WFS. Did you tick the Wipe MFT box? This option overwrites the file names held in the MFT: whether CC overwrites them with ZZ or some other name I don't know.
Recuva run in normal mode lists filenames from the MFT. WFS without the Wipe MFT option will not touch the MFT so Recuva will show the same result after running WFS as it did before.
The ZZ files have - or should have - been overwritten with zeroes. They do not need any other overwriting. These files can be recovered quite easily, but they will just be zeroes and of no interest to anyone.
WFS does not free any space at all. Secure - and insecure - deletion will. If CC says that it will delete x gb of space, and the filenames change to ZZ, then it looks as if you ran secure delete instead or as well as WFS.
2nd computer: Again, running WFS without Wipe MFT will leave the filenames in the MFT - these are what Recuva is showing. most of the filenames in the MFT will point to free space which WFS has overwritten. Some of the filenames will point to space that has subsequently been used by another file, which is still live, and this might be what you are seeing. Also small files (under 1k) can be held in the MFT entirely, and WFS will not overwrite them (nor will Recuva). Another possibility is that any locked files will not be overwritten by WFS.
One of Recuva's options is not to display zero length files. This will cause the 'x files ignored' message.
Describing CC and Recuva's little quirks lucidly and unambiguously is quite a task. I suggest you use both applications daily for eighteen months or so, you'll soon get the hang of it.
-
Ah, the ambiguities of the English language. I believe that what these two extracts are saying is:
1) Wipe Free Space is something you occasionally use to overwrite any and all files on your chosen disk that have already been deleted. WFS creates one or more large files that fill the entire disk, and then deletes them. Thus nothing that was in free space can be retrieved in its original form.
2) Secure deletion is a process you run against individual live (i.e. not yet deleted) files. CC does this by opening the file, overwriting the contents, closing it, renaming it, and deleting it. (I have simplified the process here!) So CC can only securely delete files that have not already been deleted by any method. Files in the Recycler are securely deleted by CC. If you have emptied the Recycler, or used shift/del to delete the files, you can't run CC Secure Deletion against them. You would have to run either WFS on the entire disk or use Recuva on selected files. You can run a scan in Recuva, select all the files found with the global tick box, and delete the lot if you wish.
The two options are independent, if you have deleted files from the Recycler then WFS will overwrite them. The second option discusses using Recuva to securely overwrite individual files that have already been deleted. which CC can't do.
Any more questions just ask.
-
I would also agree that you don't run Wipe Free Space (it will work on SSDs, but is rarely necessary. I have never run it). You can't defrag an SSD, and neither can you run secure file deletion, so don't run either of those options.
How often to run CC? Difficult to say as we don't know your usage. Run CC's Analyse option now and again. If you are not generating too much junk in a week, then try a fortnight, etc. You really want to get a balance between not building up too much junk and running CC as little as possible. I'm sure I could go for a month without collecting 1 gb of junk.
-
Are you not happy with the answer you received to this same question two days ago?
-
Hi Hazel, I was trying to bring a little wit into the strange nature of the forum today.
-
Overwhelmed, not a random decision (2,3).
-
No problems here. Prefetch entries aren't deleted unless they have gone 14 days (I think) without reference, and CC has never deleted the prefetch folder.
-
If you read all the thread in the link the poster states that he was actually looking at data in the MFT, and at that time I don't think that CC had the Wipe MFT option.
There's lots of threads here about wiping free space, and lots of posts saying that it's a waste of time. It's up to you whether you run it.
-
As the title says. I've just signed up for one and I'm confused, which isn't difficult. I need to chat to a Heart user. It's to do with domains and email.
-
It's the same for FF cookies too. I think it's something to do with extracting the info from these files whilst Windows is running. In any event they are cleared (deleted) at boot time whatever size they actually are.
-
It seems sensible to stop using secure deletion until this has been sorted. It sounds as if you have some corruption with the recycler. There have been other posts here with corrupted recyclers, I think that the remedy is to delete the recycler and reboot, whence Windows will create a new recycler.
I would also make sure you have a backup of your music folder to avoid further loss of data whilst you're experimenting.
-
It wouldn't really be representative as - for frequent cleaners - much of the 'cleaned' data would be the same data repeatedly loaded.
-
Anyone who has access to your pc can, by using an installed version of Recuva or a portable version on a usb drive, see all the deleted files on all the drives that you can see.
What you seem to be asking is whether the securely deleted files can be recovered by anyone. The securely deleted data cannot be recovered by anyone. The file name, size, folder info etc will remain visible as that is held in the file tables which are not accessible by Recuva.
Bear in mind that Recuva (and CC) will securely overwrite the specific data that the entry in the file table is pointing to. There may be other copies on the disk from edits, defrags and other operations.
Certain small files, less than 1k, may be held entirely in the file tables and cannot be securely deleted with Recuva.
Clean IE8 PrivacIE Index .dat
in CCleaner Suggestions
Posted
Although an occasional user of IE8, and never a user of InPrivate Browsing, I have noticed that C:\Documents and Settings\me\PrivacIE\Index.dat grows with the usual incriminating list of where I've been and what I've looked at.
I have this file - which is not locked by Windows - in my Include list, but could it be added by default to CC's list of index.dat files to delete? There's probably some other IE8 stuff as well which would benefit from being included, C:\Documents and Settings\me\Local Settings\Application Data\Microsoft\Internet Explorer\Recovery\Last Active and ...\Last Active\RecoveryStore spring to mind.
I have tested InPrivate browsing and it's useless, it just deletes your temp files as you go along, all visible with Recuva.