Opened DoPDF, a prog I haven't used for a while with no previous prefetch entry. The entry appeared in the prefetch folder, closed DoPDF.
Dragged the DoPDF entry to CC's Include secion. Ran Custom Files analyse, nothing. Ran Custom Files clean, DoPDF entry cleaned.
This was with the Old Prefetch Data checked, as it is my standard setting.
Ran it again (except that I didn't have to drag the DoPDF prefetch entry to CC's Include, as it was already there from the above). Unchecked Old Prefetch Files, ran Custom Files analyse (nothing) and clean, entry gone.
I am running analyse and clean by right-clicking the particular options in CC, so as to get a clearer view of things.
Augeas and DennisD, perhaps you as "Moderators" should contact Piriform and report this as a bug as no one from Piriform has stepped in to shed light on this matter unless they are trying to figure out what the deal maybe or, just perhaps, the belief is that the issue is not worthy of clarification?
I ran R-Wipe&Clean and it did remove all "Prefetch Traces" in the C:\windows\prefetch folder therefore, I am under this assumption that OS or my system as a whole has nothing to do with preventing files from being deleted by CCleaner.
I've found a way for you to have complete control over all the prefetch files.
Make a copy of the prefetch folder by a simple "Ctrl+left mouse click hold and drag", to an empty area of the Windows folder, or copy and paste it inside the Windows folder. You'll now have a "prefetch_2".
Then delete the original prefetch folder manually (or move it somewhere else if you want to hang onto it), and rename the copy to "prefetch".
A CCleaner analyse will show up any included files, and delete them.
I don't know if this new prefetch folder will revert to being undeletable after a reboot, as I'm busy doing something which means I won't be rebooting for some time, but you can find that out yourself of course.
EDIT: An afterthought. The renamed prefetch folder still works as it should as I tested it with Moviemaker again, and the new entry appeared as it should.
Ah ha! Dennis and Neo, a breakthough (maybe). It's the pic that holds the clue. Dennis, you're using secure deletion. I kicked off DoPDF again, created the prefetch entry (the include entry was still there), set secure deletion to one pass, ran Custom Files clean and nothing was removed!. I went back to normal deletion, ran clean, and the prefetch entry went.
Now all hangs on whether Neo uses secure deletion. I almost feel excited.
P.S. During testing I added a non .pf file to the prefetch folder. I tried to delete it and Windows didn't allow this, or a rename. Secure deletion edits, renames and deletes. Perhaps it's this?
Does CCleaners "Old Prefetch Data" routine manage to do what we can't do manually, that is delete the old prefetch data with Secure Delete enabled?
No, I've just had two more candidates for deletion through Old Prefetch Data, so I enabled secure deletion and cleaned them. Both showed up in Recuva under their proper names and not overwritten.
And does anyone really care by now?
Of course, I smell blood.
All in all that prefetch folder has some strange properties.
I can understand that a Secure delete of a message to/from a mistress might protect against divorce,
but cannot understand how deleting the prefetch files without secure overwrite would lead to divorce or any significant privacy exposure.
Chance would be a fine thing (Wistful sigh).
Personally, I leave the prefetch to CCleaners "14 day without access" routine, but as I have a 1 pass secure delete set for CCleaners general cleaning, purely as a result of the direction this thread has taken I was curious as to whether CCleaner was securely deleting eligible prefetch files with that blanket setting, but it appears not.
Ah ha! Dennis and Neo, a breakthough (maybe). It's the pic that holds the clue. Dennis, you're using secure deletion. I kicked off DoPDF again, created the prefetch entry (the include entry was still there), set secure deletion to one pass, ran Custom Files clean and nothing was removed!. I went back to normal deletion, ran clean, and the prefetch entry went.
Now all hangs on whether Neo uses secure deletion. I almost feel excited.
P.S. During testing I added a non .pf file to the prefetch folder. I tried to delete it and Windows didn't allow this, or a rename. Secure deletion edits, renames and deletes. Perhaps it's this?
What was I saying about "Catch22"?
I can't test this on my computer now as my "new" prefetch folder shows up in a scan with "1 Pass Secure Delete" enabled.
Although .. I haven't rebooted since the substitute thing.
Greetings and sorry about the delay in reply but here, we had a 3-day weekend and I was gone.
My setting is on normal file deletion. I Included a .pf file (from the prefetch folder) and proceeded with "Analyze custom files and folder". Nothing showed up but, this time when I initiated "Clean" even though nothing was detected, CC confirmed deletion of the .pf file!!! Same process failed when I set CC to "Secure delete w/ one pass". No file was removed.
Funny thing is, I followed your procedure and added a non-PF file in the folder, I set to secure delete and the file showd up in analysis of Custume files and folders and was deleted as well.
With regards to creating a duplicate prefetch folder, I agree and confirm that all .pf files within the new folder successfully were detected and removed as if OS or CC did not care about contents of the new folder that bears name of prefetch but is NOT created by the OS during OS installation. DennisD, perhaps that is why your new folder shows up in the analysis as it is NOT the one created by the OS during installation. The one that most likely is tagged, referenced, documented, coded, ...somewhere