Nurick

Thanks for setting me in the right direction with the "Last Accessed" mention! But the solution is a little more complex than simply that CCleaner uses Last Accessed date. BOTTOM-LINE SOLUTION seems to be: If you have Windows 7, ensure Date Accessed functionality is Disabled, which is the default. As long as that’s the case, CCleaner will use Date Modified (aka simply “Date”) in determining whether a file meets the user-set age parameter for deletion. That’s the desired, no-surprises, behavior. My problem was that (although I had thought otherwise) I had Date Accessed Enabled. DETAILS (for the record...I’m not sure many will want to read and try to follow ): Experimentation showed that the CCleaner date rules for custom file deletion were indeed using Date Accessed (which seemed kind of odd to me, although I could see it making more sense for *Temp* files, where there is the recommended “only delete older than 24 hours” option.). Well, it turns out that there are ways Date Accessed, when enabled, can change (become more recent), even without manual access by the user. (That’s beyond the scope of this post, see links below.) Now, Date Accessed is actually *disabled* by default in Windows 7 (again see the links below). Its value can still be viewed, but it most cases it will just be the same as Date Modified. But at one point a few years ago I had enabled Date Accessed via the method described in the links. Despite some old documentation to myself saying I had re-disabled it afterward, apparently at some point I had reversed course and re-enabled it again (or perhaps I hadn’t actually *successfully* re-disabled it?). In any event, when I first posted -- as it turns out -- Date Accessed was still enabled. Well, I re-disabled Date Accessed today, hoping this would keep files' Date Accessed values from being changed “behind the scenes” and thus throwing off the CCleaner Custom-folder-cleaning time parameter. Anyway, after I re-disabled Date Accessed (i.e., back to the Win 7 default), CCleaner switched to using *Date Modified* instead in determining the age of the file. So it is now working fine, as I initially expected, no surprises. (This is true even for old files copied or moved from another folder, despite the fact that copying. -- as some commenters mention in one of the links -- still changes Date Accessed to the current date/time in the copy, i.e. the same as the new Date Created. A file-move will also change Date Accessed to the current date/time, even though a move will *not* change Date Created. Neither copy nor move changes Date Modified.) One caveat: Over the years I have had Win 7 I've seen a few minor oddities in file behavior -- none of which cause any significant problems -- with regard to file dating behavior, so there is a possibility this fix was specific to my system. But I doubt it. http://www.febooti.com/products/filetweak/online-help/file-last-accessed-date.html http://www.groovypost.com/howto/microsoft/enable-last-access-time-stamp-to-files-folder-windows-7/

Windows 7 Pro. Yes to uninstall, reboot and reinstall. No difference in Safe Mode. The files in question are far older than 48 hours (created and modified dates), specifically unneeded files from 2013 that I moved to the folder I want time-restricted cleaning for, just for testing.

Thanks. Here's the INCLUDE line: Include1=PATH|C:\Screenshoter_JPGS\|*.*||1|0|48 Here's the entire INI file, with the individual cookies-to-save list removed. Note that, other than browser cache and cookies, I do minimal routine browser and system-file cleaning. [Options] UpdateKey=12/22/2014 11:42:03 PM WipeFreeSpaceDrives=C:\ CookiesToSave=<Cookie list shows up here> RunICS=0 Monitoring=1 SystemMonitoring=0 CheckTrialOffer=0 Include1=PATH|C:\Screenshoter_JPGS\|*.*||1|0|48 (App)Custom Folders=True (App)History=False (App)Recently Typed URLs=False (App)Delete Index.dat files=False (App)Last Download Location=False (App)Recent Documents=False (App)Run (in Start Menu)=False (App)Other Explorer MRUs=False (App)Thumbnail Cache=False (App)Taskbar Jump Lists=False WINDOW_MAX=1 WINDOW_LEFT=263 WINDOW_TOP=58 WINDOW_WIDTH=966 WINDOW_HEIGHT=725 SystemMonitoringRunningNotification=0 LastMonitoringNotificationTime=11/03/2014 06:02:00 PM LMN=2|3|0|0|0|0|1|0|0|0|||| SystemMonitoringNotificationTime=01/18/2016 02:59:00 AM (App)7-Zip=False (App)ActiveX and Class Issues=True (App)Adobe Acrobat 9.0=True (App)Adobe Flash Player=True (App)Application Paths=True (App)Applications=True (App)Autocomplete Form History=False (App)Chkdsk File Fragments=False (App)Clipboard=False (App)Cookies=True (App)DNS Cache=False (App)Empty Recycle Bin=False (App)Fonts=False (App)Gom Player=True (App)Help Files=False (App)Installer=True (App)Interface=True (App)Invalid File Extensions=False (App)MS Management Console=False (App)MS Office Picture Manager=False (App)MS Paint=False (App)MS Search=False (App)MS Wordpad=False (App)MUI Cache=False (App)Memory Dumps=False (App)Menu Order Cache=False (App)Missing Shared DLLs=True (App)Mozilla - Compact Databases=False (App)Mozilla - Cookies=True (App)Mozilla - Download History=False (App)Mozilla - Internet Cache=True (App)Mozilla - Internet History=False (App)Mozilla - Session=False (App)NVIDIA Install Files=False (App)Office 2003=False (App)Office 2013=False (App)Office 97=False (App)Old Prefetch data=False (App)RegEdit=False (App)Run At Startup=False (App)Sound Events=False (App)Start Menu Ordering=False (App)Temporary Files=False (App)VLC Media Player=False (App)Winamp=False (App)Windows Defender=False (App)Windows Error Reporting=False (App)Windows Event Logs=False (App)Windows Log Files=False (App)Windows Media Center=False (App)Windows Media Player=False (App)Windows Services=False AnalyzerTypes=1|1|1|1|0|0|0 BackupDir=C:\Users\Nurick\Desktop Brandover=0 DelayRB=0 DelayTemp=1 FinderInclude1=PATH|C:\|*.*|RECURSE|0|0|24 FinderInclude2=PATH|M:\|*.*|RECURSE|0|0|24 FinderInclude3=PATH|P:\|*.*|RECURSE|0|0|24 FinderInclude4=PATH|W:\|*.*|RECURSE|0|0|24 FinderInclude5=PATH|X:\|*.*|RECURSE|0|0|24 FinderInclude6=PATH|Z:\|*.*|RECURSE|0|0|24 FinderIncludeStates=1|1|1|1|1|1 Language=1033 NewVersion=5.01.5075 ShowCleanWarning=False SkipUAC=1 SystemAnalyzerDrives=C:\

After I enabled INI files I saw that CCleaner had already generated an "Include1" line that looks exactly like the one you suggested (but of course with a different path and 48 instead of 336 -- and without RECURSE since I was not requesting subfolder deletion). And unfortunately the problem persists. I re-tried with subfolder deletion but that didn't change anything. I also thought that maybe the fact that the target folder isn't user-specific might be an issue, so I tested with a user-specific folder and the problem remained. But thanks for the suggestion, anyway. Anything else you think might be worth a try?

No thoughts? This seems like a pretty straightforward question. Would someone mind taking a couple minutes to see if he/she can replicate the issue? If so, I can be more confident in reporting it as a bug. Thanks!

For several years I have used the "INCLUDE Additional Files and Folders to Remove" option to delete all the files from one particular folder every time CCleaner runs. That has worked fine. Recently I decided I would instead prefer that CCleaner delete only files older than 48 hours from this folder, and was pleased to see that there is an option where I can specify this. Unfortunately, I have found that after I edited my rule by ticking "Only Delete Files Older Than 48 hours" (I had to specify the 48, of course), CCleaner stopped deleting *any* files from the folder, regardless of age. I have tried deleting and re-creating the rule from scratch, and also updating to the latest version (5.13.5460), but neither move resolved the issue. If I untick the file-age restriction, it still works fine for deleting *all* files from the folder, but I'd prefer to have the "older than 48 hours only" functionality. Any suggestions as to how to make this work? Windows 7.

Thanks. (I tried to give you a "Like" but my quota must still be set at zero.) I'll probably go with your sensible advice not to make any registry changes simply as an attempt to eliminate the checkbox. But if anyone else has any further observations/suggestions, please pass them along.

Hi. Today I noticed that under Multimedia I have Gom Player listed as a cleaning option in CCleaner, but I do not have that program (I had never even heard of it). It wasn't there the last time I checked the Multimedia section, which would have been at most a month ago, probably less. The checkbox was unticked when I noticed it. I Googled Gom Player and see that it is a media player made my Gretech. It is not in my list of installed programs. I also thoroughly searched the files on my C drive and do not see any entries for GomPlayer or Gretech. I searched the registry for the same, and found a few empty-value entries for Gretech Gomplayer. I then ran CCleaner Registry Cleaner, as well as another registry cleaner, expecting them to flag these entries as obsolete or unneeded, but neither one did. Any idea what might be going on? Could it be that this was installed by some other program, which then uninstalled it when the main program was uninstalled? I guess it doesn't hurt having that checkbox there, but I'd prefer that it wasn't since I don't have Gom Player. As for the registry cleaners not flagging the GomPlayer entries, is it perhaps normal for the registry to retain blank entries for software that has been removed? But if so and that's why the checkbox is there, wouldn't CCleaner options always be bloated with cleaning checkboxes for no-longer installed programs? Thanks.

Thanks. At least for recycle bin scans, I seem to get just one or the other for a deleted file, either the $Innnnn or the $Rnnnnn, but not both. But moments ago a deep recycle bin scan turned up empty for all my partitions, except for two files (a text file and an mp4) I emptied from the bin a few minutes earlier. Is this a normal occurrence? Could that result be cause by the scheduled (weekly) defrag Windows 7 ran last night? If so, is it best to make defrag less frequent? (Fyi, after a few more minutes of experimentation -- and maybe Windows or other programs doing some writing behind the scenes -- only one of the two files is still showing, an mp4 which showed as original_filename.mp4, 56MB on the first scan, and now as $IY2KA78.mp4, 544 bytes as expected with the $I.)

Wow! I wonder if that means that the one file that was (initially) shown as recoverable (one of the largest, 770MB) is the first one I wrote to the flash drive? I can't tell now because I've reformatted that flash drive to NTFS, but I do believe it was one of the older files. Later, when I have more time and and collect more datapoints (I saw some patterns in early experimentation), I'll write about the problems I am having with recovery in NTFS. But a quick preview of one of the things I'm running into most is that the recovered just-deleted (from the recycle bin) file is often quickly found and marked in excellent condition -- but it is in fact reduced in size (usually to 544 bytes, at least for an mp4), and needless to say is corrupt and unusable. (For certain file types, notably pdf, I'm having much more success.) And I'm only having the problem on my OS partition, not any of the other four partitions on the hdd. If you or anyone else has any initial thoughts on this now (before I experiment further and post more detail, as a new thread), any input is of course welcome, but I'm pretty tied up with other things for the next week or two.

Thanks. Even though I'm still having a lot less success with Recuva and other recovery programs than I used to in XP (maybe related to how I migrated my data to Win7??), looking into it a bit further shows that the particularly-strange behavior like that described in my first post seems unique to the FAT32 thumb drive.

Since moving from Windows XP to Windows 7 in March, I've been having very little luck with Recuva. Files I try to recover are shown as overwritten nine out of ten times, seemingly regardless of the size, age or original location of the file I'm trying to recover. Tonight I was trying to recover a 50MB file I had just deleted from a 16gb thumb drive. Minutes after deleting the file (and without any further use of the drive) I wanted to get it back. Using Deep Scan for all deleted files, 33 files were found. The one I wanted, and 31 of the others, were all marked as unrecoverable because they were overwritten. Ironically, the only deleted file marked recoverable (in excellent condition) was a two-year-old file that is by far the largest of the 33, at 770MB. 28 of the files -- including the one I wanted to get back -- were marked as overwritten by one specific 867MB file (an mp4 video, call it ABC.mp4) that is about 6 years old, and that I haven't accessed in at least a year. As a test I then tried deleting two more files I no longer need (a 53MB mp4 and 321MB mp4) and then ran Recuva. Sure enough they were both shown as unrecoverable because they were overwritten by ABC.mp4. This is FAT32 drive, but subsequent experimentation with an NTFS thumb showed a similar pattern. Any thought on what might be going on? I also tried a different recovery program which similarly showed the just-deleted files as overwitten (although that program doesn't identify the overwriting file), so it may not be a Recuva-specific issue. EDIT: To experiment a little further, I created a 4kb text file, saved it, and immediately deleted it. It is shown as recoverable. But now that one previously recoverable file (the 770MB one) is also shown as unrecoverable because it was overwritten. But NOT by ABC.mp4. Instead the overwriting file is that 4kb text file I had just created and deleted (and there was 1.36GB of free space when I did so).

Very helpful explanation, Alan_B. Thanks! I do have to say that depending on a "clever little tweak" makes me a tad nervous, although I assume CCleaner tested it carefully before adding the function? Is the tweak readily explainable? Or perhaps proprietary? Also, could you expand a bit on what "unless Windows is already broken" means? Do you mean to a point where System Restore wouldn't even function (or is infected)? While I definitely agree with both of you that XP's System Restore is often ineffective and quirky, and in some cases create more problems than it solves, it has really hugely saved the day for me in more than a few instances. Those particular rescues have definitely outweighed the headaches it's caused other times. Ironically, several of the times SR did a big rescue for me it deleted all restore points in the process -- kind of like knocking down the bridge as soon as I got across it (which means no "undo" option had I decided I really wanted to be back on the other side). In retrospect I wish I knew whether any of the major "rescues" were using points that post-dated points I had deleted via CCleaner, just to reinforce the comfort level. I do use imaging software as well, but create images only about once a month.

I still use Win XP-SP3 home. Awhile back I read (from a very reputable source, as I recall), that XP-Home restore point are only save system information that is incremental or changed vs. the previous point. (Although, come to think of it how could that be, if each point eventually becomes the oldest one as points drop away one-by-one, first-in-first-out?? Wouldn't that always render the oldest remiaining point incomplete?) Anyway, assuming the idea of only-incremental updating is true, doesn't that mean it would always be risky to delete any but the oldest restore points? I.e. if you have occasion to use the 14th restore point to try to restore the system, but you've deleted points 11, 12 and 13 via CCleaner, wouldn't that keave restore point 14 with incomplete system information?

I want to have CCleaner delete XP system temporary files, but NOT any that are in subfolders of Documents & Settings (because sometimes there are Office documents in there that are handy to have for recovery).. Is there a way to specify this? I didn't see any folder exclusion options. Since the system temp files I'm primarily interested in having CCleaner delete are those in Windows\Temp, I tried setting that up as a custom folder clean (and un-ticking Temporary Files from the System clean options). This *would* be fine, except that I don't want system temp files that are less than 48 hours old deleted. And apparently the advanced option to restrict system Temp deletions to items older than 48 hours doesn't apply when Windows\Temp is specified via the custom folder clean route. Any thoughts on how I can set CCleaner to delete Windows\Temp files older than 48 hours, but leave all temp files within Documents & Settings intact? Thanks.