Winapp2.ini on skates - making it 40 times faster.

[Tr3bg0D]

 

This uses 80 columns by 38 lines when run.

The "Mode Con:" fix on line 2 should no longer be needed, so I have disabled with a preceding "REM".

 

 

Ran several more tests on x86 and x64...no problems. THe screen output also fit very well on my Netbook.

[Tr3bg0D]

@Alan - I just had an idea for improvement and avoid issues....tell me what you think

 

Make the BAT file do all the work for you. That is, have it copy its working files (EXE and INI) to a subfolder it creates within the BAT file and then run its script. This way, if a user accidently runs the BAT file from within the folder the EXE resides in, no harm done. Only issue I see is to make the APP portable since you will need a PORTABLE.DAT file and it will have to be created on a fly like "echo #PORTABLE# > TRIM\PORTABLE.DAT"....of course TRIM is the working folder.

 

Just a thought

[Alan_B]

Ran several more tests on x86 and x64...no problems. THe screen output also fit very well on my Netbook.

Thanks, good to know.

[Alan_B]

@Alan - I just had an idea for improvement and avoid issues....tell me what you think

 

Make the BAT file do all the work for you. That is, have it copy its working files (EXE and INI) to a subfolder it creates within the BAT file and then run its script. This way, if a user accidently runs the BAT file from within the folder the EXE resides in, no harm done. Only issue I see is to make the APP portable since you will need a PORTABLE.DAT file and it will have to be created on a fly like "echo #PORTABLE# > TRIM\PORTABLE.DAT"....of course TRIM is the working folder.

 

Just a thought

I am not happy about the consequences of running my script within a "working CCleaner Folder" because :-

it adds several temporary #??? files during course of execution as part of an audit trail of changes it makes ;

Its operation stipulates the cleaning of absolutely every item in a WinAp22.ini file,

and that should be safe because it never invokes such cleaning - it only wants the debug output,

but I do not know what effects this might have on the future operation of this same "working CCleaner Folder" should it affect the settings in either the registry or CCleaner.ini.

 

Would it be helpful if I stipulate that my script MUST be placed in a folder dedicated to its function,

and that for user convenience this folder may be a subdirectory of a "working CCleaner Folder",

and that IF this folder holds no CCleaner.exe / CCleaner64.exe / WinApp2.ini then it will copy what it needs from its parent.

That is a simple code change for me and avoids prompting the user for a source drive and path from which to copy.

[Tr3bg0D]

Alan...I am in total agreement with you about running the script in the same folder as ccleaner.exe and it should be in its won folder.

 

Would it be helpful if I stipulate that my script MUST be placed in a folder dedicated to its function,

and that for user convenience this folder may be a subdirectory of a "working CCleaner Folder",

and that IF this folder holds no CCleaner.exe / CCleaner64.exe / WinApp2.ini then it will copy what it needs from its parent.

That is a simple code change for me and avoids prompting the user for a source drive and path from which to copy.

Basically this is what I had in mind. The BAT file can be started within the CCLEANER folder and the script creates a subfolder and copies its needed files....of course it will have to check to see if the files exists, and it can even create a BAT file to work with. Lemme try and throw together something together from your latest script and I'll PM it to you.

 

BTW, just ran a test. IMHO, the script should abort if ccleaner*.exe, Portable.dat and winapp2.ini don't all exits. I just ran it to the end with no winapp2.ini.

[Alan_B]

Basically this is what I had in mind. The BAT file can be started within the CCLEANER folder and the script creates a subfolder and copies its needed files....of course it will have to check to see if the files exists, and it can even create a BAT file to work with. Lemme try and throw together something together from your latest script and I'll PM it to you.

O.K. - Should be simple.

If trim*.bat finds CC*.exe in folder below, it assumes the "standard CC working folder" is below and it is in its private playground,

and if it needs then it copies the CC*.exe and Win*.ini to its playground and does the job.

 

If trim*.bat cannot see CC*.exe below, but finds the CC*.exe is in the same folder, it then creates its private prayground in a subfolder, copies itself there, and transfer control there.

 

If Trim*.bat cannot see CC*.exe in either place it gives an appropriate message and stops.

 

BTW, just ran a test. IMHO, the script should abort if ccleaner*.exe, Portable.dat and winapp2.ini don't all exits. I just ran it to the end with no winapp2.ini.

I only wrote it to follow the rules I created for myself - but I am happy to allow the user more flexibility than Microsoft allows me

[Tr3bg0D]

OK, I think you got what I mean. This way if a user makes and error, the script does not follow that error. But you need to check/create a PORTABLE.DAT file or else it will read/add to the registry.

[Alan_B]

@ Tr3bg0D

 

I think this should be suitable :-

 

This can reside in a working CCleaner folder and require no User actions to copy CCleaner*.exe or WinApp2.ini.

It creates all the temporary files in a child subdirectory called #Trimmer.

It concludes by offering to update the current .\WinApp2.ini with the new .\#TRIMMER\WinApp2.ini.

Later I may offer to cleanup by removing #Trimmer

 

It should be safe to use in an installed version of CCleaner that depends upon the registry.

 

I have not tested UAC aggravation because my past experience was that UAC only objected to my launch of CCleaner* /Debug.

Please let me know if the UAC test should be done earlier than at the moment.

 

Please edit your version of Trim_8.bat and insert the following code block below the third line

"CD /D %~dp0 & REM All files are here, not at stupid "Run As Administrator" default %windir%\"

 

DEL /Q #TRIMMER
IF NOT EXIST #TRIMMER\NUL MD #TRIMMER
SET "RES=" & SET "ast=*"
FOR %%a IN ("CCLEANER^!ast^!.EXE" "WINAPP2.INI") DO (
 IF NOT EXIST #TRIMMER\%%a COPY %%a #TRIMMER >NUL 2>&1 || SET "RES=!RES! %%a ; "
)
ECHO #PORTABLE#> #TRIMMER\Portable.dat
IF "!RES!" NEQ "" ECHO( %~nx0 Requires these :- !RES! & PAUSE & EXIT /B

CD #TRIMMER
ECHO Launching Trimmer code %TIME%
CALL :DoFixWinni
CD ..

SET Fndx=0
for %%W in (.\WinApp2.ini .\#Trimmer\WinApp2.ini) do (
 SET /A Fndx+=1 & SET "Dat!Fndx!=%%~zW bytes"
 SET "Dir!Fndx!=%%~ftzW"
 SET "Data!Fndx!=%%~tW   %%~zW "
)

:LOOP123
ECHO NEW= !Data2! #Trimmer\Winapp2.ini
SET "ANS=" & SET /P ANS= "OLD= !Data1! Winapp2.ini - (U)pdate or (N)o :  (U or N) ? "
IF /I "!ANS:~0,1!"=="N" PAUSE & EXIT /B
ECHO( & IF /I "!ANS:~0,1!" NEQ "U" GOTO LOOP123
ECHO Replacing .\WinApp2.ini with .\#TRIMMER\WinApp2.ini

COPY /B /Y #TRIMMER\WinApp2.ini WinApp2.ini
DIR WinApp2.* /T:W | FIND ":"
PAUSE & EXIT /B

:DoFixWinni

 

Oops Just spotted some debug code I failed to strip,

but I leave it here for now in case it is the only thing keeping the code afloat

 

@ APMichael

 

I need to rationalize the names of variables and temporary files and then I will add "exclude.txt" and issue Trim_9.bat

[Tr3bg0D]

Will let you know later today how it went

[Tr3bg0D]

@Alan

 

I ran this on a few systems (still going to test on a couple more) and it works well. I have been running it with and without UAC emulation by altering this line:

Set "ANS=C" & RD !UAC! 2>NUL & RD !UAC! 2>NUL || (

 

Only 2 things which bothered me and one I was able to fix:

1 - I Changed the 1st line from this:

DEL /Q #TRIMMER

to this:

IF EXIST #TRIMMER DEL /Q #TRIMMER

 

2 - I've noticed a period at the start here: . Hit "Enter" key when ready to proceed ...

I noticed code change in that area.

 

I will be testign this on my Netbook later today to see how it fits on the screen.

[Alan_B]

The patch I supplied to put on top was like a wig - you can see the join

 

I have now smoothly integrated the patch with the rest of the code,

and almost completed addition of Exclude.txt ready for release tomorrow.

 

1.

I have now merged the first and second lines to :-

IF NOT EXIST TRIMMER\NUL DEL /Q TRIMMER 2> NUL & MD TRIMMER

That ensures that if a file called Trimmer is present, the code will detect it is not a folder, and then it will be deleted so there is no obstacle to block creation of the folder.

 

2.

I wanted a large space before the words and without a period before the space there would have been no space.

I have now refined that region.

 

 

Regards

Alan

[Alan_B]

Trim_9 is now here. Just rename Trim_9.txt to Trim_9.Bat

 

This needs to be in a folder together with WinApp2.ini and CCleaner*.exe, and optionally with #_Exclude.txt

This MAY be the same folder in which CCleaner is installed for normal daily use.

This is now my preferred mode of operation.

 

To avoid potential damage to the settings of the normally installed CCleaner,

Trim_9 creates a child sub-directory #TRIMMER for all its processing.

It creates the file #_NEEDED.LST which identifies all the WinApp2.ini check-boxes relevant to the system.

You may copy items from #_NEEDED.LST into #_Exclude.txt and when Trim_9 runs again those items will be excluded,

giving an even smaller WinApp2.ini.

 

It concludes by offering to update the "original" version of WinApp2.ini with the new "TRIMMED" version,

and then offers to purge the child sub-directory .\#TRIMMER\

#_Exclude.txt is NOT located in .\#TRIMMER\ so it is preserved from purging.

 

Using CCleaner64.exe v3.15, and WinApp2.ini Version: v1.0.120125,

there are 743 entries, of which 21 are Volatile Detections that are shown in

#_7_BAD_MINI_WINAPP2.INI

and 65 of these entires are relevant to my P.C., and these include 4 Volatile Detections as per

#_8_BAD_MINI_WINAPP2.INI reports - e.g.

1062 1418 {Detect} {HKLM\SOFTWARE\Microsoft\Tracing} WHOOPS - BAD DETECTION 4

1062 1420 {RegKey1} {HKLM\SOFTWARE\Microsoft\Tracing} BAD DETECTION ZAPPED 4

 

This is the relevant entry

[Windows Tracing*]
LangSecRef=3025
Detect=HKLM\SOFTWARE\Microsoft\Tracing
Default=False
RegKey1=HKLM\SOFTWARE\Microsoft\Tracing

 

This is my quick bodge to overcome volatility

[Windows Tracing*]
LangSecRef=3025
Detect=HKLM\SOFTWARE\Microsoft\
Default=False
RegKey1=HKLM\SOFTWARE\Microsoft\Tracing

 

That may be a bad solution for other WinApp2.ini because even if they have no ...\Tracing to deal with,

detection would probably be triggered by

HKLM\SOFTWARE\Microsoft\.NETFramework

 

Regards

Alan

Trim_9.Txt

[Tr3bg0D]

Ran Trim_9 on my Netbook and works well. Will play more later with this new version.

 

Couple of things.

 

- Can you expand a bit on the #_Exclude.txt? I am unclear on its function.

- THUMBS on aborting with no WINAPP2.INI present

 

Also a suggestion. In the previous version, I was doing some testing on systems with UAC ON. Each time I ran the script, it failed even though I allowed it to go through when the pop-up appeared. IMHO, I feel you should abort the script if UAC is detected and it is not "Run as Administrator".

[Tom AZ]

A general question . . . do you re-run the "Trim" routine after each Winapp2.ini update -- or after adding new software -- or both?

[Alan_B]

A general question . . . do you re-run the "Trim" routine after each Winapp2.ini update -- or after adding new software -- or both?

Yes to both.

 

When a new update is issued you can choose to ignore it.

I normally left it a few months because the latest bits never detected anything more to clean than before.

HOWEVER

My "working CCleaner" is version 3.14 and with Firefox UN-ticked but all other Applications and All Windows Ticked it finds 61.9 MB to be Removed.

My "Experimental" version 3.15 with "latest" WinApp2.ini (Version: v1.0.120125 with 743 entries) is ready to "go ape" on 489 MB

 

Once you update WinApp2.ini you have lost all the speed benefit of previous use of Trim_*.bat until you run it again.

 

Once you have run Trim you destroy recognition of anything that does not need recognition because it is not installed,

so new software can then be added but will not be cleaned unless :-

1. CCleaner.exe itself is already coded by Piriform to seek and destroy, or

2. You Download WinApp2.ini again so it can recognize the new software, and then Trim_*.bat will allow the new detection to survive.

 

WARNING New software will not be detected by WinApp2.ini, regardless of the use of Trim_*.bat, unless :-

a. It adds the registry key or file/folder upon which detection is based ; OR

b. You have used the software and it has created the junk files/folders upon which detection is based .

[Alan_B]

- Can you expand a bit on the #_Exclude.txt? I am unclear on its function.

APMichael requested this feature in post #72 to make the Trimmed output even smaller and faster to load.

He illustrated its application by avoiding the WinApp2.ini *check boxes for ShellBags and MUICache.

I assume that he has in mind a far larger set of detections that he wished to exclude.

 

On my system Trim_9 cuts the download by 91%, from 743 entries to 65 entries,

and the Analyze button is UN-greyed and active within less than 1 second of double clicking the CCleaner64.exe,

so I have no need to make it faster.

 

C:\ is 24.9 GB with only 9800 MB in use (including 489 MB of junk CCleaner is poised to attack),

and less than a total of 1 GB used in two other partitions.

The rest of my 1 TB primary HDD is unallocated ( and virus free )

Perhaps if I was like some ( I name no names - you know who you are )

and I had 1 TB of applications there would be a lot more junk to clean, and a far larger "detected" portion of WinApp2.ini,

and then Trim_*.bat would remove far less than 91% of the detections,

and if the individual user thinks 50% of the detections are to risky then #_Exclude.txt will make his CCleaner.exe start-up twice as fast.

 

N.B. I am happy with my "working CCleaner" removing only 62 MB.

With all check-boxes ticked (apart from Firefox) it wants to take out 102 MB.

There is 40 MB I need to evaluate before I destroy.

 

With the new capability of wiping out 489 MB I am headed for a new and different experience - which I may have cause to regret.

 

For myself CCleaner is "ready for instant action" after using Trim_*.bat without needing #_Exclude.txt,

BUT I will probably use #_Exclude.txt so the empty check-boxes I dare not tick will no longer waste screen space, and I will not have to scroll past them.

 

Also a suggestion. In the previous version, I was doing some testing on systems with UAC ON. Each time I ran the script, it failed even though I allowed it to go through when the pop-up appeared. IMHO, I feel you should abort the script if UAC is detected and it is not "Run as Administrator".

 

I only detect the capability to remove the folder %windir%\AdminTest_EVIL_UAC.TMP

and from any failure deduce that UAC has interfered - but there could be other reasons so I allow the script to proceed if the user so chooses because the end result could still be good.

Other reasons, which may still apply even when "Run as Administrator" :-

I.T. restrictions that prevent users from deleting the contents of %Windir%;

Malware protection software that prevent users from deleting the contents of %Windir%;

Existence of %windir%\AdminTest_EVIL_UAC.TMP as a FILE and NOT a folder.

 

Unless any damage is caused, I prefer to let the user continue to operate the script.

It may well waste a few seconds time attempting the impossible,

but it is always possible there could be success - especially on an XP system which is not under the curse of UAC.

 

Thanks for all your testing and feed-back,

especially for your suggestion that saves the user from downloading Portable CCleaner.exe to a dedicated folder..

I found it very convenient for both further developments and debugging of this software,

and will continue to use it this way whenever I decide it is time to update WinApp2.ini.

 

Regards

Alan

[APMichael]

Great, trim_9.bat works flawless with #_Exclude.txt. Now I have a perfect matching winapp2.ini with just a double click. Thank you very much.

 

I have a suggestion for an additional "bad" entry check: Can you check if all entries of the original winapp2.ini have a trailing asterisk (*) in their names? Because without the asterisk the entry is ignored by trim.bat.

[Alan_B]

Thanks for Feedback, glad you like it.

 

I see an easy tweak to my code that will both detect and correct the absence of a trailing asterisk.

Hopefully I will be able to post this afternoon a two line patch - but I will test it first

 

Regards

Alan

[Tr3bg0D]

Thanks for the additional info on the #_Exclude.txt....I will do some testing/playing.

 

Some things I noticed on Trim_9.

- Is the #TRIMMER folder to be nuked when you start the script? In the previous version, all the files were removed and now I am noticing they are just getting overwritten.

 

I made a couple of chages in the script I use.

 

Line 54

Changed from this: pause

to this: ECHO( Press any key to continue . . . & pause >nul

 

Line 139

Changed from this: SET /P ANS= "D)elete or ®etain child folder .\%WORK%\ : (D or R) ? "

to this: SET /P ANS= "(D)elete or ®etain child folder .\%WORK%\ : (D or R) ? "

 

One anomoly that I am not able to isolate is with my Firefox temp files I want to nuke. Sometime the completed INI file contains them and sometimes it does not. I have not been able to figure out why. I am running a Portable version of Firefox and even of the files are/not currently present, I want to make sure they are nuked. These are the sections missing:

 

[Extensions Logs*]

LangSecRef=3026

DetectFile=%AppData%\Mozilla\Firefox

Default=False

FileKey1=%AppData%\Mozilla\Firefox\Profiles\*|extensions.log

 

[Crash Reports*]

LangSecRef=3026

DetectFile=%AppData%\Mozilla\FireFox\Crash Reports\

Default=False

FileKey1=%AppData%\Mozilla\FireFox\Crash Reports\pending|*.*

FileKey2=%AppData%\Mozilla\FireFox\Crash Reports\submitted|*.*

FileKey3=%AppData%\Mozilla\FireFox\Crash Reports|*.*

 

[Dump Files*]

LangSecRef=3026

DetectFile=%AppData%\Mozilla\Firefox

Default=False

FileKey1=%AppData%\Mozilla|*.dmp|RECURSE

 

Anyone have any ideas of what is happening????

[Alan_B]

Existing code plus surrounding context :-

:DO_TRIM
ECHO Trimming trailing spaces, IP = %1 : OP = %2
SET /A SPC=0 & CALL :SET_LO_HI %1
CALL :T_N
<%1 (
 for /L %%b in (!LO!,1,!HI!) do (
set "LN=" & set /p "LN="
if "!LN:~0,1!"=="[" SET /A OP+=1
SET "HEAD=!LN!" & SET "TAIL=" & IF "!HEAD:~-1!"==" " SET /A SPC+=1 & CALL :DO_TAIL %%b
ECHO(!HEAD!
 )
)> %2
CALL :T_N_S Found !VAR! lines, !SPC! needed Trim
EXIT /B

The central two lines need replacing with

SET "HEAD=!LN!" & SET "TAIL=" & IF "!HEAD:~-1!"==" " SET /A SPC+=1 & CALL :DO_TAIL %%b
if "!LN:~0,1!"=="[" SET /A OP+=1 & IF "!HEAD:~-2!" NEQ "*]" SET "HEAD=!HEAD:~0,-1!**]"

That detects a line starting with '[' but lacks the terminating '*]'

and replaces the last character with '**]'

 

This ensures that :-

Trim_* will recognize and use this a a valid entry to be included ;

The CCleaner GUI shows the check-box is NOT built-into CCleaner, but comes from WinApp2.ini ;

The "powers that be" can easily get a report of what could be improved, e.g. via CMD.EXE, as per :-

E:\T\CCleaner\New\T9>FIND "**]" < #TRIMMER_1\#_#_WINAPP2.INI

[Eset Online Scanner**]

[spybot Search & Destroy Updates**]

[uTorrent Bar Logs**]

 

E:\T\CCleaner\New\T9>

 

N.B.

I saw your comment in the WinApp2.ini Additions about the Spybot error

and Trim_* "raises you two"

 

Regards

Alan

[Alan_B]

Thanks for the additional info on the #_Exclude.txt....I will do some testing/playing.

 

Some things I noticed on Trim_9.

- Is the #TRIMMER folder to be nuked when you start the script? In the previous version, all the files were removed and now I am noticing they are just getting overwritten.

 

I decided to retain it because :-

All the output files automatically replace the entire original so there was no need to purge before use ;

There was no point in deleting the copy of CCleaner.exe and then copying afresh ;

Windows refuses to allow the deletion of the folder if I had opened one of the files with notepad and forgotten to close notepad .

It would be nice if Windows told me WHAT was keeping the folder "in use" - but after about 30 years I guess that is not happening any time soon

 

I will take your code comments into consideration, but am about to take a meal break.

 

So far as Firefox is concerned, you seem to have a "Volatile Detection" effect, but I see no cause within WinApp2.ini.

 

I can only suggest that perhaps Firefox itself occasionally cleans up what WinApp2.ini is detecting.

Perhaps Firefox does this automatically, or maybe as a result of one of the Piriform options to Vacuum / optimize databases etc.

 

Regards

Alan

[Alan_B]

Line 54

Changed from this: pause

to this: ECHO( Press any key to continue . . . & pause >nul

The only visible difference when CCleaner has been launched, analyzed, and closed,

is that you have shifted to the right by one character the message "Press any ... "

 

What I do NOT LIKE is the difference between the display whilst it is waiting for the user to press the key.

 

The original code has a high visibility flashing cursor just to the right of the unfinished business " . . . "

and it is "obviously" waiting for user action.

When the user presses a key then :-

If you click on the DOS Window to recapture focus when CCleaner.exe launches,

OR if it never loses focus because CCleaner.exe falls over and fails to launch,

then it will be seen that the cursor is no longer waiting for user action,

but has gone down one line and appears on the left,

just like it does when the script has posted a message and CMD.EXE is busy on the next task before the next message.

 

The proposed change results in my eyes reading the message that concludes " . . . "

but the flashing cursor that says "my turn" is not where I am looking,

but on the next line down and half a DOS window to the left,

exactly where it normally flashes when we are waiting for CMD.EXE to execute the next bit of code etc.

Even worse, my DOS window has a bright border surround the dark contents,

so a flashing cursor adjacent to the bright border takes longer for me to notice.

 

I am happy to consider any counter-arguments.

 

Line 139

Changed from this: SET /P ANS= "D)elete or ®etain child folder .\%WORK%\ : (D or R) ? "

to this: SET /P ANS= "(D)elete or ®etain child folder .\%WORK%\ : (D or R) ? "

You got me there. Now fixed, thank you.

 

That was my last chunk of code to remove #TRIMMER,

and I took too long fixing an operational bug, so not enough time examining the final display.

 

The operational bug was that #TRIMMER was "In Use" for no good reason and could not be removed.

I had to close down each of several dozen windows, one at a time,

before I found the culprit was Notepad that had at some time opened one of the files in #TRIMMER,

and needed to be closed

 

Regards

Alan

[APMichael]

Thanks for the two patch lines. I changed the code to this...

<%1 (
 for /L %%b in (!LO!,1,!HI!) do (
set "LN=" & set /p "LN="
SET "HEAD=!LN!" & SET "TAIL=" & IF "!HEAD:~-1!"==" " SET /A SPC+=1 & CALL :DO_TAIL %%b
if "!LN:~0,1!"=="[" SET /A OP+=1 & IF "!HEAD:~-2!" NEQ "*]" SET "HEAD=!HEAD:~0,-1!**]"
ECHO(!HEAD!
 )
)> %2

...and everything works fine. All the entries without an asterisk were found and fixed. Now this is really the ultimate tool for a perfect trimmed winapp2.ini!

 

Could a moderator pin this useful thread please?

[Alan_B]

Trim_10.bat is Safer and Better.

 

SAFETY :-

 

Winapp2.ini is very effective.

It is able to remove 490 MB from the 9500 MB Used Space on C:\

 

That is equivalent to the chiropodist putting down the nail clippers and picking up a chainsaw.

A danger of being cut-off at the knee and not being able to walk again

That is why the script warns :-

YOU MUST NOT "Run Cleaner" - ONLY Click "Analyze"

 

For safety Trim_10 now excludes all registry / file / folder deletions from the temporary WinApp2.ini when /DEBUG expects ANALYZE,

and if by error you "Run Cleaner" in this mode the WinApp2.ini targets will NOT be deleted,

(but of course all Piriform CCleaner.exe defaults will apply).

N.B. If you do "Run Cleaner" when you should only "Analyze" the accuracy of creating Mini-Wini could be degraded - don't do it.

 

As a bonus, because the targets are not stipulated the "Analyze" is much faster because it does not have to measure the 490 MB size of my target junk.

 

BETTER :-

 

1.

Winapp2.ini has 743 entries, and a few have more than one detection item, but I only considered the last item in each entry as being potentially volatile.

There is a total of 792 detections, 49 of which were not considered.

There were 21 volatiles in 743, so I expected approximately 1.38 within the 49 not previously tested.

The latest version considers every detection, and still finds only 21 volatiles in a total of 792 detections.

 

2.

I have added the option

@_#_?_BAD_*.LST Volatile Detections - (P)reserve or (S)kip : (P or S) ?

On my system that places in the parent folder copies of

#_7_BAD_FULL.LST which lists 21 volatiles in all 792 Detections, and

#_8_BAD_MINI.LST which lists the 4 volatiles that are KNOWN to be relevant to the 65 out of 743 entries on my system.

After using this option I have 82 entries that will be cleaned if they should pop-up.

By manually removing #_7_BAD_FULL.LST then CCleaner will still have all 65 check-boxes for the 4 known volatiles,

regardless of whether the detection item has temporarily vanished.

 

3.

Along with the single line fix that ensures each entry identity concludes with **] or *]

the new single line below that ensures that the Default is always False.

 

Just download Trim_10.txt and rename as Trim_10.bat

 

The file #_Exclude.txt will exclude not only the entries within WinApp2.ini, but also any includes found in #_?_BAD_*.LST

 

Regards

Alan

Trim_10.Txt

[Tr3bg0D]

SNAGGED for more testing.

 

Just ran it on my x86 and works fine. Will work on other systems later.

 

Suggestion: (I went brain dead the last couple of days as I kept forgetting to PM you about this)

Toward the end of the script, you prompt to Overwrite the OLD INI with the NEW INI. If you select to SKIP, next question asked is if you want to remove the #TRIMMER folder.

I would say if the user does not overwrite the INI file, the prompt to delete the #TRIMMER folder should be skipped so it can be manually copied. Just my 1cent....sorry, didn't get paid for 2cents.