Augeas

Are you trying to recover the directory structure? If so untick this option and try recovering to a specific location, preferably not to your hard drive, either another partition or a flash drive.

They appear to be created by Webroot Spysweeper. I know nothing about this software so I don't know how to remove them, apart from uninstalling. but it's a clue.

You quite willingly paid twenty bucks under the impression that this would enable you to remove an obstinate program. With assistance from forum members and CC you eventually cleared the program, and were very happy (post 17). Now you want your money back. Why do you no longer think it was worth paying for?

Yes, more or less. If you want one file to be overwritten securely then either highlight the entry or check the box and then right-click and do the business. If you want a block of files to be overwritten securely then highlight or check the boxes as above. If you want several files to be overwritten securely whose entries are not adjacent to each other then you will have to use the check-box method, as highlighting will not 'stick' on multiple entries. The end result is the same. When you securely overwrite a file the original is destroyed at the time of overwriting. If it is recovered you will only see the overwritten data.

There's no difference in the deletion method, merely in the selection of entries to be deleted. Whichever one you use is up to you. Highlighting is easy for quickly selecting a block of entries, and checkboxing is required for selecting separate non-contiguous entries (which highlighting won't do). The overwritten entries, or rather the data they point to, don't go anywhere, they are, as it says, overwritten. Although you can recover an overwritten file with Recuva or other software it will just be zeroes or a random string of chars. The entry name is not overwritten as it is not possible to do this safely.

There doesn't seem much point in defragging sys restore points. You will never read then in normal life, if you're doing a sys restore then a few milliseonds access wait won't be your greatest problem, and they are deleted and created on a rolling basis, so you'll be forever chasing your own tail.

Once CC is installed the chosen language is embedded in the exe, so the entire contents of the lang folder can be deleted (I get CC to do this). I'm not sure about a second language. You can't just switch from one to another without a reinstall, can you? Do you just want the id's of the Eng and French modules so you can do that? Unfortunately my lang folders are empty. There may be better ways of doing this. Install both the English and French portable versions on a flash drive for instance, and save 1.75 mb compared with the measly few k that the lang files take up.

As far as I know it doesn't mean that these file extensions are unused (perhaps a slightly misleading term). After all CC doesn't scan your entire disk just to see iif you have a .xyz file hanging around. I think it means that there is a registry entry for these extensions but it is not associated with any program. You may well have hundreds of them, if you attempt to open one then Windows will ask 'What with?'. I used to have quite a few, some with very peculiar extensions. After a rebuild I have none, and if any do pop up from time to time I remove them, with no ill effect so far.

Are you running a deep scan? Whilst this might be necessary later I would suggest first running a normal scan with show undeleted files ticked. If you do try a deep scan then keep the show undeleted files box ticked.

Yo dudes, (I really must stop watching silly films.) This wasn't intended to be should I-shouldn't I clean prefetch - that's been done to death elsewhere - but a comment that should you analyse prefetch and then save the list to a text file it appears to update the prefetch last accessed date, so you can't then clean them. Just a comment, I don't do this very often. I have rather a feeble list of files in my prefetch folder, fewer than 100, so Windows never maintains it. Good old CC gets rid of unused for 14 days files, which is why I use this option. What peeves me about prefetch is that it's a great idea, but the layout file includes a huge amount of tat I don't want optimising at all, such things as sys restore points, lang dlls, umpteen fonts, recent document lists, temp internet files, etc. Where on earth do they come from? I guess it's pulling them from stuff that applications load at run time. But sys restore logs? I wonder if CC is somehow triggering this, as it's the only app I use to look at sys restore points.

You would continue unperturbed with the original index.dat file. I, and no doubt countless others, do this all the time. I have found that some of the contents of index.dat are removed when CC is run, presumably related to the deletion of temp int files. I guess that the index.dat file would still be deleted on reboot, but to be honest I've never bothered to check.

I toyed with Badcopy from www.jufscoft.com some time ago, and it scanned and extracted deleted data from a CDR like magic. It's small and an easy install. The trial version doesn't let you save the found files, just scan them, but in doing this the files are extracted to a temp file on your hard drive, so you can use Recuva afterwards to recover the files, one at a time. That's sneaky I guess.

Unfortunately we don't know the answers, except to question 2, which in my opinion should be don't run CC registry cleaner until you get an answer.

The proof of the pudding (apologies, English phrase) is whether not cleaning the registry cures your problem. If it does, then some aspect of registry cleaning is the cause. Unless you can isolate the cause then the best solution is not to clean the registry. (My experience is that most Dutch people, even those living in France, speak English better than most English people.)

I opened CC and right clicked/analyse on Old Prefetch, and up came 33 files out of 95 I have in the prefetch folder. This is good - get rid of all that old tat that is pointlessly being included in Layout.ini and defraged every few days. I really don't want to prefetch umpteen esoteric lang files, sys restore stuff, guff that couldn't possibly be of use any more. I saved CC's list to a text file, looked at the prefetch folder and sorted the contents in last accessed order. It appeared that anything not accessed for 14 days would go. Goody. I then went back to CC and right clicked on Old Prefetch, and there was nothing to delete. I still have all 95 files in the prefetch folder and the 33 set to be removed now had a last accessed date of today. Sorting the prefetch folder contents in last accessed date didn't alter that date so I can only assume that CC's analyse or save to text file did. The moral is don't redo the anaylse. Go in with the delete. As I have the text file I will delete the 33 prefetch files manually. That'll teach 'em.

Nergal is correct. Despite all those fancy words (delete, erase, wipe, wash, clean, scrub, etc) the only thing you can do to a disk or flash drive is write to it. Files that Recuva thinks are securely deleted have an entry in the MFT, and that entry points to (what we hope is overwritten) space on the disk. The MFT entry and the disk space will be overwritten with further use. I don't know how Recuva classifies securely deleted files. It can't be the all ZZZZs name, as some are occasionally listed with the non-securely deleted files. As Recuva and CC are applications writing data there's nothing in NTFS or Windows that says 'This file has been securely deleted.' It's just data, and secure deletion merely a concept.

Almost certainly (by that I mean that there is no provision in CC to delete them, unless the complete mail pst file was manually entered in the Include section) CC did not delete your emails. And the reverse is true, almost certainly Recuva will not be able to find them, unless the complete pst file has been deleted. Emails are held in the pst files in some sort of direct access method unique to OE. Emails have to be managed by IE. No doubt there's some add-on or something that lets you delete all old emails in one fell swoop, but CC doesn't do this. There is a Clean Up Now option in OE Maintenance but I've never used this so I don't know what it does. Maybe something like this was poked into life. I mean dbx files, as Jamin rightly states.

CC does not touch emails so I think that there is another reason for your loss. What email client are you using?

Me three. Neat, elegant, comprehensible.

I much prefer the cleaner (no pun intended), more elegant display, it's far more readable, although I can see the frustration of those who opt for the full file list to be shown and then lose it on subsequent CC close/open. I don't really want to plough through all the entries when I'm cleaning - I often run clean without analysing - and it's very easy to show the full list if that's what's wanted. The option of seeing and sorting by filesize is worth moving to 2.22 on its own. And the option of opening the containing folder - did we have that before?

I guess Bartowsky was deleting cookies previously and now isn't. When I run a full analyse or right click and analyse on IE and FF cookies I get no results (yes, I have plenty to delete). Is the new version not picking up cookies? Later... I take it all back, CC is finding cookies. I must have had a little brain fade, it happens from time to time.

Not quite. Folder $Recycle.Bin is the recycler in Vista. When you delete a file to the recycler it goes into $Recycle.Bin. When you delete a file from the recycler it is set as free space. The structure of files in $Recycle.Bin is different in Vista from XP: they exist in pairs named $I.... and $R..... From memory I think that the $I is the info file (the file name. location, date deleted, etc) and $R is the data. Displaying the contents of the folder shows the 'real' file names, of course. I don't know why CC would find one set of files in the recycler using normal deletion, and another using secure deletion. I don't know if there has been some interruption of the deletion process that may have left some corruption in the $I/$R pairing or CC's analysis stage. That's only a guess. The next time I do a CC normal delete I'll run a secure delete afterwards to see what happens.

Perhaps if the error is 'The RPC server is unavailable' you could try turning on the Remote Procedure Call service. One of its long list of dependencies is the System Restore Service - and another is the Secrity Center, which you may wish to have enabled.

Recuva does work of course, preumably for many thousands or more people. If you click on the State column header the file list will be sorted in state order (but don't take the state as absolute, try a recovery anyway). If you select No to Do you want to restore to the same drive, this should return you to the recovery location box, so you can select somewhere else, if you have anywhere else to recover to. Unfortunately I don't know why Recuva is failing, I can't remember ever getting this message. I used to have problems when trying to display a lot of thumbnails, but was fixed some time ago. If your laptop has extremely slow performance and frequent freezing then Recuva might be a secondary victim of this. 'Recovering some MS Windows program files' sounds scary, it would be better to reinstall or repair than using Recuva to do this.

Hi Mr G, I'm interested to see that you support exFat drives, more specifically that you mention defragging flash drives. (I know that some geeks will insist on installing an exFat system on a hard drive, but exFat was intended for flash drives and this is what I'm concentrating on.) Numerous posts on this forum, and inumerable posts on the great web out there, say that it's a waste of time to defrag a solid state device. After all, the whole concept is just wrong, how can you possibly reduce head movement on a SSD? What benefit would it be to have contiguous data on a SSD? Fuirthermore, most if not all SSDs have some sort of wear levelling protocal, where data is written pseudo-randomly across the device so that one area is not used any more than anywhere else. As this (I guess) resides in the internal flash controller then the defragger won't be able to override it so that the result of the defrag will be randomly scattered data, just the same as it was before the defrag started. I will readily defer to Mr G and the Piriformer's superior knowledge and experience in these matters. I'm just curious. I dare say that if exFat is easy to implement then it makes Defraggler more comprehensive. Maybe it's similar to Gutmann, pointless but customer demand.