Jump to content

CCleaner still uses registry for 1 user promt


mr don

Recommended Posts

I love the ability of CCleaner to store settings in the ini file.

 

I get annoyed on new pc's you clean, or actually, on old ones each time it tells you that you are going to be deleting files, are you sure you want to proceed?

It really adds up on hundreds of machines.

 

I was wondering if you'd consider adding the ability to disable the "Are you sure you want to really delete files?" in the ini file, instead of using the registry.

 

Thanks!

 

Hope you like this idea!

Link to comment
Share on other sites

Mr. Don,

 

Are you using CC v2.30 ?? Because in that version the file ""CCleaner.ini"" can contain an entry/line indicating whether CC needs a confirmation for starting the cleaning process or not.

 

e.g. ""MSG_CONFIRMCLEAN=False""

This setting (False) surpresses the confirmation before starting the actual cleaning.

 

The crucial point is that only AFTER the first time the user has changed this particular setting (by ticking a box in CC called ""Don't show me this message again"" in the confirmation warning message-window, see attachment) that line is added to ""CCleaner.ini"" by CC. If there's no entry called ""MSG_CONFIRMCLEAN=....."" then CC wants a confirmation before starting the actual cleaning.

 

And in order to make CC ask for a cleaning confirmation again, the user must edit ""CCleaner.ini"". Either delete that particular entry or change that entry to ""MSG_CONFIRMCLEAN=True"". Because there's no option available in CC to switch that setting back to ""True"".

 

The story above made a question surface. Perhaps the user should be able to select and unselect this particular confirmation option. And then I think this option should be placed in the ""Advanced"" section (""Options"", ""Advanced"").

 

Mr. Don, there's another thing you should do. Create a file in the application folder called ""portable.dat"". If CC v2.30 detects that file then it doesn't store any settings in the registry any more.

 

""Note: The portable version of CCleaner 'knows' that it is portable because of the presence of the file portable.dat in the application folder. If CCleaner finds the file portable.dat in the application folder, it will always save its settings to CCleaner.ini. The contents of the portable.dat file do not matter - you can create a dummy file."".

Source:

http://docs.piriform.com/ccleaner/advanced...rs-ini-files-do

 

Perhaps you need to uninstall CC, clean the registry and re-install CC again, in order to get rid of those (pesky) CC registry entries ?

 

(the underlined sentences were the latest addition to this post)

Edited by Willy2

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

I want to add a number of things to post #2 of this thread.

 

CC v2.30 always makes a number of changes in the Windows registry, even when CC settings are stored in the file ""CCleaner.ini"".

 

This leads to another suggestion for CC. Perhaps it's possible to introduce an option in the CC installation program to perform an installation without ANY changes to the registry.

 

The ""/AUTO"" option in CC doesn't pose a problem because Windows XP always checks a number of locations in order to see which programs are to be run on startup. e.g.

1. the registry.

2. a folder on my (dutch) computer (with Windows XP) called ""C:\Documents and Settings\--Username--\Programma's\Menustart\Opstarten"". Storing a shortcut to CC in that particular folder forces Windows to run CC on startup as well.

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

Willy2

 

Not criticising, just wanting to clarify.

 

I agree with your first post that Portable.dat keeps everything out of the registry and only changes the *.INI file.

 

Have you now found that Portable.dat fails with version 2.30, and is it CCleaners fault ?

 

I have not yet fully committed to the latest version,

but my experience is that the registry is changed when running almost portable application.

It is not the fault of the application, but the Comodo Security System Defense+.

When I run RegShot and use any utility to delete a file,

the Defense+ Behavour Blocker gets involved,

and decides whether to let it happen, or to ask if it is allowed,

in which case Regshot will record IN THE REGISTRY the name of the utility and that decision and action.

 

I now prefer to Switch my security into my "Special Mode" when evaluating portability,

i.e. Internet fully blocked and A.V. plus Defense+ etc disabled.

 

Regards

Alan

Link to comment
Share on other sites

Alan,

 

It may sound presumptious but I DO think I have found the reason why CC fails to remember a changed setting as decribed above by ""mr don"". I know it could not be confined to that one setting only. I think that in a particular set of circumstances CC, as a result of this bug (!!), even could fail to remember a significant amount of previous changed settings. Yes, it's ""portable.dat"" related. And I already gave a hint where to look for that error.

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

Willy

 

I think you misunderstand me.

 

I fully accept that you may have found the problem.

 

I was thinking of asking you to share,

but fortunately I reviewed and found that you added the information as per :-

This post has been edited by Willy2: Yesterday, 01:51 PM

 

I posted my question at 3:33 p.m. without consideration of that information,

and possible more than 2 hours earlier than your edit because this may be one of the forums where posts are given time stamps based upon the local time hence 1:51 pm in USA may correspond to 5:51 pm in U.K. ! !

 

So - not arguing - just seeking clarification upon whether Portable.dat is perfect as suggested by your first post,

or whether it has limitations as indicted by your second post.

 

I have now copied ccsetup230.zip to C:\Program Files\CCleaner on XP Home Edition with SP3

I disabled all protection, with Internet blocked, and launched regshot.

I took a snapshot of the system, unzipped the ZIP, took a second snapshot, compared, and got :-

 

Regshot 1.8.1

Comments:

Datetime:2010/4/15 20:05:31 , 2010/4/15 20:06:29

Computer:ACER-311VPBCEH0 , ACER-311VPBCEH0

Username:Alan , Alan

 

----------------------------------

Values modified:4

----------------------------------

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG\Seed: 0F 56 0D F8 A9 D3 F0 80 64 6C 91 36 BD 99 9F F9 68 FF C5 54 5C 14 E5 D0 B4 61 12 60 25 C6 F3 53 C5 D8 42 64 44 79 27 D1 1E 65 70 78 39 EF 51 4A 9F 2A 3D FC 31 9C 5C 92 A1 91 08 11 DC 76 F3 4D 10 8E 78 BE 96 0F D0 BD FE 16 88 01 7B 86 4D 2A

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG\Seed: CB 0E 5E 26 C0 B9 0C 1A 34 80 13 35 D7 0C 39 D7 27 AB 7D BA A9 CE D2 38 57 2F 81 45 FC 32 4C 5C BA 54 52 55 4E 51 81 F3 66 F4 97 26 78 E6 2A 12 87 47 91 F1 B6 67 0C 93 3B F6 32 F5 5E A9 89 66 48 87 34 4E 7D F8 63 AB 44 E1 07 92 26 81 33 B0

HKEY_USERS\S-1-5-21-2390561323-618324915-1863506564-1008\Software\PowerArchiver\Stats\51: 0x00000027

HKEY_USERS\S-1-5-21-2390561323-618324915-1863506564-1008\Software\PowerArchiver\Stats\51: 0x00000028

HKEY_USERS\S-1-5-21-2390561323-618324915-1863506564-1008\Software\PowerArchiver\Stats\73: 0x00000023

HKEY_USERS\S-1-5-21-2390561323-618324915-1863506564-1008\Software\PowerArchiver\Stats\73: 0x00000024

HKEY_USERS\S-1-5-21-2390561323-618324915-1863506564-1008\Software\PowerArchiver\Stats\438: 0x00000122

HKEY_USERS\S-1-5-21-2390561323-618324915-1863506564-1008\Software\PowerArchiver\Stats\438: 0x0000014D

 

----------------------------------

Files added:45

----------------------------------

C:\Program Files\CCleaner\CCleaner.exe

C:\Program Files\CCleaner\lang\lang-1025.dll

 

This is me again ! ! ! - don't want to waste space with the remaining 43 files ! ! !

And then :-

----------------------------------

Files [attributes?] modified:5

----------------------------------

C:\Documents and Settings\Dad\ntuser.dat.LOG

C:\Program Files\DigiGuide TV Guide\user-settings\logs\2010-04-15-v1-dg.log

C:\System Volume Information\_restore{F6EA6CAA-B744-447E-8F9E-B9A9507C7CB4}\RP1107\change.log

C:\WINDOWS\Prefetch\POWERARC.EXE-37FF1F0A.pf

C:\WINDOWS\system32\config\software.LOG

 

----------------------------------

Folders added:1

----------------------------------

C:\Program Files\CCleaner\lang

 

----------------------------------

Total changes:55

----------------------------------

End of comparison

 

Note, the last entry in

C:\System Volume Information\_restore{F6EA6CAA-B744-447E-8F9E-B9A9507C7CB4}\RP1107\change.log

This refers to

\ P r o g r a m F i l e s \ T o o l s \ R e g S h o t \ l a n g u a g e . i n i " A 0 2 8 2 4 9 4 . i n i

 

That entry is NOT due to CCleaner - it is my fault, I should NOT have installed regshot on C:\Program Files.

For some reason Regshot "refreshed" its language.ini, and the evil presence thought I might need to restore its previous content ! ! !

 

Other file changes show that my TV Guide told me it was time to switch on the T.V. for a favourite program.

And of course the evil presence wastes a bit more time doing a prefetch for the unzip utility so the Unzip will start slightly, very slightly, faster if I ever need it again this month ! !

 

CONCLUSION - In answer to my original question :-

 

The Portable version does not alter the registry when it is unzipped.

the only effects on the registry were the evil presence of Microsoft\Cryptography\RNG\Seed watching everything,

and PowerArchiver doing something which has caused me to decide it will be removed next week and replace with a PortableApps 7ZIP utility.

 

Tomorrow I will get a portable version of Regshot running in another partition,

and observe Registry etc. consequences of Analysing and then of Cleaning.

 

Regards

Alan

Link to comment
Share on other sites

I now have Regshot 1.8.2 on another partition.

 

Simply launching and closing down CC updates C:\Program Files\CCleaner\CCLEANER.INI

That is a bit wasteful when there have been no changes,

and a bit nasty that every time a needless re-write is done to this INI,

another copy is preserved for System Restore.

In practice I only use CCleaner running in Drive H:\ which is NOT aggravated with System Restore.

 

In addition there was another prefetch file, but there is no escaping them.

 

The registry captured

HKU\S-1-5 ... etc ... \Software\Microsoft\Windows\ShellNoRoam\MUICache\C:\Program Files\CCleaner\CCleaner.exe: "CCleaner"

but the only way to avoid that is to not run the executable ! ! !

 

There were quit a few kmixer things, e.g.

HKLM\SYSTEM\ControlSet001\Services\kmixer\Enum\Count: 0x00000001

But that is not unique to CC ! !

 

I was really intrigued by

HKU\S-1-5 ... UserAssist\{75048700- ... }\Count\HRZR_EHACNGU:P:\Cebtenz Svyrf\PPyrnare\PPyrnare.rkr:

I do not have a drive P:\ - unless I have been hijacked ! ! !

 

I found Cebtenz Svyrf\PPyrnare\PPyrnare.rkr was reported as being found on CCleaner 2.21.940

see http://www.checkfilename.com/view-details/...Index/0/sTab/2/

It was assesed as innocent.

 

I really did not like having a drive P:\, so I searched "Count\HRZR_EHACNGU"

Only 6 Google results, each about whether it was spyware etc,

I am not the only one that worries - there are at least 6 more people like me in the world ! !

 

Working through a few links I got to

http://www.tele-pro.co.uk/scripts/misc/rot13.htm

That shows me that

HRZR_EHACNGU:P:\Cebtenz Svyrf\PPyrnare\PPyrnare.rkr:

corresponds to

UEME_RUNPATH:C:\Program Files\CCleaner\CCleaner.exe:

The reason for concealment is not deceit, but privacy, as stated in the above link :-

The Rot13 cypher is used to obfuscate text in the Windows registry, to make captured data on your browsing habits and recent files less noticable.

 

The link below shows that CCleaner did not do this, but it was done by the evil presence

http://niiconsulting.com/checkmate/2006/05...pyware-utility/

 

SUMMARY :-

In the words of The Hitch Hikers Guide.

"Mostly Harmless" ! !

 

Regards

Alan

Link to comment
Share on other sites

Thanks Hazel, yes that was interesting.

 

My thoughts about Rot13 cypher are that it is unexpectedly good of M.$. to protect the privacy of my browsing habits,

and other voices are telling me :-

Political Parties are not the only employers of Spin doctors; and

Rot13 cypher is an exceptionally effective way to conceal from P.C. Users how M.$. is scrutinising all we do and think ! !

 

 

After the previous ANALYZE only session, I did a complete Analyze then RunCleaner then Analyze,

and have now scrutinised the regshot results.

 

Regshot reported all the files and folders that were deleted,

and reported the file attribute change to Cleaner.ini,

and saw the previous version of ccleaner.ini renamed and copied to restore Point as

C:\System Volume Information\_restore{F6EA6CAA-B744-447E-8F9E-B9A9507C7CB4}\RP1108\A0282510.ini

 

The registry had more changes to things like

...\UserAssist\{7 ... 9}\Count\HRZR_EHACNGU:P:\Cebtenz Svyrf\PPyrnare\PPyrnare.rkr: 46 00 etc. etc.

and several

HKU\S-1-5-21- ... -1008\Software\Microsoft\Windows\ShellNoRoam\BagMRU\0\MRUListEx: 04 00 etc.etc.

 

 

CONCLUSIONS

When ccsetup230.zip is unzipped it does nothing to the registry, but evil presence records its arrival in

HKU\S-1-....\Software\Microsoft\Windows\ShellNoRoam\MUICache\

...\UserAssist\{7 ... 9}\Count\HRZR_EHACNGU:P:\Cebtenz Svyrf\

etc.

 

When it purely analyzes, or analyze and run cleaner, it also does nothing to the registry,

but again evil presence makes copious notes in the registry.

 

When actually cleaning, there are extra things happening to the registry as files/folders are removed,

but none of the extra things appear to implicate CCleaner.

 

I trust CCleaner that it will not write any of its own settings into the registry whilst it is cleaning the registry, but cannot prove it.

I cannot see any convenient way to clean 10,000 registry "issues" and to then confirm perfect correlation with all the registry changes that are seen by Regshot.

 

VERDICT - Portable CCleaner is truly portable and does not use the registry.

 

Suggestion :-

Deploy it on a non-system drive if you wish to avoid updating System Restore with a new copy of CCleaner.ini

 

But remember, when it runs, no matter where it has been deployed, evil presence is watching you ! !

 

Regards

Alan

Link to comment
Share on other sites

Alan,

 

I hope the story below will clarify a lot of what I have been writing about. The information below is ""According to my information"".

 

Information in both posts #2 and #3 is accurate. I'll explain. ""mr. don"" experienced problems with one particular setting because it seems he used a particular sequence of changing settings to configure CC (incl. creating ""Portable.dat""). And then CC can fail to remember e.g. that the setting ""MSG_CONFIRMCLEAN=....."" was changed to ""False"" over and over again and that's what annoyed ""mr don"". That particular sequence of configuring also can make CC ""forget"" a number of other settings.

 

To avoid that problem the user must create ""Portable.dat"" first BEFORE changing any CC settings. Then CC doesn't fail to remember the changed settings. But one can't expect every user to know that. So, when the CC installation program would offer the user an option to create a ""Portable"" version right off the bat, then - at least - ""Portable.dat"" and perhaps ""Ccleaner.ini"" could be created automatically, before the user starts to configure CC. Perhaps such a ""Portable"" CC could do without any or only minimal changes to the registry. And that was what I was refering to in post #3.

 

The ""Portable CC"" does makes changes in the registry. If the user selects/de-selects ""Run CC on startup"" then CC adds/removes some information to/from the registry in spite of ""Portable.dat"" being present.

 

My favourite and - IMO - the simplest and therefore the best solution is to get rid of ""Portable.dat"". CC could focus on detecting ""Ccleaner.ini"" instead. If it exists then CC could read the settings from that file and store all new settings there. If ""Ccleaner.ini"" doesn't exist then CC should read the registry and save the settings there instead.

 

That would combine perfectly with the ""Save settings to INI file"" option. Selecting this option in v2.30 copies all relevant registry settings to ""Ccleaner.ini"" and removes them from the registry as well. De-selecting that option copies that information from ""Ccleaner.ini" to the registry and deletes that file. So, then there's no chance anymore of having two sets of contradictory information.

 

But I haven't got a clue whether eliminating ""Portable.dat"" would have broader implications for CC. At least, it gives the Piriform folks something to chew on.

Edited by Willy2

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

The ""Portable CC"" does makes changes in the registry. If the user selects/de-selects ""Run CC on startup"" then CC adds/removes some information to/from the registry in spite of ""Portable.dat"" being present.

That may be true, but it is not valid.

With ANY "Portable" application that status is violated as soon as it modifies Windows Startup.

 

Otherwise I do not disagree with anything you have said.

 

I think however there is no problem if the Portable version is chosen,

because as soon as you unzip it you not only have CCleaner.exe, but you also have Portable.dat and CCleaner.ini.

 

I think therefore we are looking at the situation of installing the wrong non-portable installation,

and then converting to saving to INI,

in which case what about the existing registry settings of CCleaner ?

Should CCleaner be instantly truly portable and leave the registry alone ?

in which case the registry settings will still show that the Save to INI is still not checked

Or should it start its Portable life by a non-portable action of either updating or deleting its registry keys ?

 

I accept that only using the presence of CCleaner.INI could be nice.

 

There might be a few "Gotchas" though.

e.g after using as a portable, what if the Advanced menus cancel the "Use INI" option, and then close.

Presumably the settings are now written to the registry.

What about CCleaner.ini - can that be left as it was - should it be updated - should it be deleted.

If those are the only 3 possibilities a decision is fairly easy, but each of those possibilities may need further decisions.

 

I believe CC is now written in 'C', and was previously coded in a different language.

There may be code written by some who have moved else-where and did not document well.

 

I have suffered myself when having to update ancient software and as soon as I fix one piece of functionality an unrelated piece turns out to have had an unexpected dependency.

 

The simplest changes to software are the most likely to cause problems as dormant bugs are unleashed ! !

 

So far as the original problem is concerned, I believe :-

If the Portable version is used, complete with Portable.Dat and CCleaner.ini,

that MUST remember the setting ""MSG_CONFIRMCLEAN=....."" within CCleaner.ini and not touch the registry,

and if it does not then it should be reported as a bug, not a mere suggestion.

 

If the non-portable version is used, and then the user decides to "go portable"

I can understand glitches across the transition.

After shutting down and then restarting as a fully portable application,

if ""MSG_CONFIRMCLEAN=....."" is stored once more it should this time be held in CCleaner.ini,

and this should be retrieved and used on future start-ups,

otherwise it should be reported as a bug, not a mere suggestion.

 

Regards

Alan

Link to comment
Share on other sites

Alan,

 

Yes, I agree, there're a lot of things that can go wrong and that's why it's important to choose the simplest solution.

 

The sequence of changes is currently very important.

If CC detects ""Portable.dat"" the settings in the registry are neither copied to ""Ccleaner.ini", nor wiped. The registry is simply ignored and the information is still there. So, let's assume the setting ""MSG_CONFIRMCLEAN=False"" was generated and written to the registry. Then the user created ""Portable.dat"". After that CC doesn't copy that setting from the registry to ""Ccleaner.ini"", it's simply ignored. The next time CC is forced to read ""Ccleaner.ini"" (and ignores the registry) it doesn't find a ""MSG_CONFIRMCLEAN=....."" line over there. It then reverts to the default value (""True""), although in the registry the value of that setting is still recorded as ""False"". That's an example of how settings are overlooked.

 

If CC detects ""Portable.dat"" then the option ""Save settings to INI file"" is automatically ticked and the user can't untick it.

 

However, there could be another very simple and straight forward solution: don't use the registry for storing (the majority of) settings but always write (the majority of) them to ""Ccleaner.ini"". Then ""Ccleaner.ini"" is always up to date and then the ""Portable.dat"" and the ""Save settings to INI file"" option can be eliminated. A good example of ""K.I.S.S."" (Keep It Simple, Stu**d).

Edited by Willy2

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

I accept your observations.

 

I think this may be worth submitting as a bug report, but could it be a design feature ?

 

If this "MSG_CONFIRMCLEAN=..." is the only thing that does not go in the CCleaner.ini,

could it be deliberately excluded from use by the Portable variant ?

 

Everything within CCleaner.ini that controls whether or not to clean something is under menu control.

i.e. You can launch CC and uncheck or check a box to control one aspect,

and when you close the new value is written to CCleaner.ini ready for the next time.

At a later stage you can change your mind.

 

I can see no check-box to control this "MSG_CONFIRMCLEAN=..."

I think that once you have chosen to delete and been prompted and confirmed,

you are on a one-way trip with no way to get another prompt and to cancel the "continuous authority".

This could be inconvenient on a single computer.

It could be much worse of hundreds of different computers and software packages have this safety feature removed by one act of "continuous authority" upon one portable flash drive.

 

If there is only a way one trip, that is a bug / inconvenience that should be fixed.

It is a "problem" which Portable users do not face ! ! !

 

Perhaps it was a safety feature in-case the average local handyman added a flash drive to his toolkit of pipe-wrenches etc. Business card :- Mr Fixit , mends roofs, un-bungs drains, and repairs computers.

 

I am certain that Mr. Don has no need to be protected in this way,

but I think it regrettable that we should have a one-way trap from which the only escape is to manually edit the INI.

 

I vote that the "MSG_CONFIRMCLEAN=..." should be :-

held in the INI;

and easily controlled to either condition by a checkbox.

 

Alan

Link to comment
Share on other sites

Alan,

 

There?s another issue with the sequence of changing settings as described in post #12.

 

Suppose the user has unticked all boxes in both ""Windows"" and ""Applications"" and has added a total of, say 40 lines in both the ""Exclude"" and/or ""Include"" sections. All these settings and information are stored in the registry. When ""Portable.dat"" is created after that, then CC doesn't read the registry anymore. Just imagine the frustration of the user when it appears that CC has forgotten those 40 added lines in the ""Include"" and ""Exclude"" sections and sees that a number of boxes are ticked again without his consent.

 

Another thought crossed my mind. CC could offer an option to create a ""Portable"" version, e.g. in the ""Advanced"" section. That would involve two actions 1) Move the settings from the registry to ""Ccleaner.ini"" 2) Create ""Portable.dat"". Then the transition to a ""portable"" version is controlled and without any glitches.

 

But - IMO - the best solution for handling the settings issue, is to get rid of ""Portable.dat"" as described in post #10 or #12 of this thread.

 

 

As I have stated before: ""A discussion always stimulates the braincells"" !!!! We'll have to wait and see if CC v2.31 will include any of my/our suggestions.

Edited by Willy2

System setup: http://speccy.piriform.com/results/gcNzIPEjEb0B2khOOBVCHPc

 

A discussion always stimulates the braincells !!!

Link to comment
Share on other sites

I agree it would be better to avoid dependence upon Portable.dat.

 

I would say a workable sequence for all existing versions of CC should be :-

1. Check the box "Save all settings to INI" ;

2. Close CCleaner so the settings are stored in the INI ;

3. Add Portable.dat to the folder.

 

I gained that knowledge through hard experience - not from any FAQ.

It would be far better if others are protected from problems due to lack of "need to know information".

 

A simple "bodge" might be that if Portable.dat exists,

then CC MAY BE portable, but only if :-

CCleaner.ini exists, and has checked the option "Save all settings to INI",

Otherwise CC will simply get the settings from the registry,

and when CC closes if that option is set then CCleaner.ini will automatically be created.

 

Regards

Alan

Link to comment
Share on other sites

  • 2 months later...

Suppose the user has unticked all boxes in both ""Windows"" and ""Applications"" and has added a total of, say 40 lines in both the ""Exclude"" and/or ""Include"" sections. All these settings and information are stored in the registry. When ""Portable.dat"" is created after that, then CC doesn't read the registry anymore. Just imagine the frustration of the user when it appears that CC has forgotten those 40 added lines in the ""Include"" and ""Exclude"" sections and sees that a number of boxes are ticked again without his consent.how to plan a wedding

Link to comment
Share on other sites

  • 2 weeks later...

However, there could be another very simple and straight forward solution: don't use the registry for storing (the majority of) settings but always write (the majority of) them to ""Ccleaner.ini"". Then ""Ccleaner.ini"" is always up to date and then the ""Portable.dat"" and the ""Save settings to INI file"" option can be eliminated. A good example of ""K.I.S.S."" (Keep It Simple, Stu**d).

The registry exists for a reason: performance (of the system, not necessarily of CCleaner). This idea is well-intentioned but would force all CCleaner installations--portable or not--to be poorly behaved Windows apps. Doing that in the name of making portable use absolutely seemless is a crappy trade-off.

 

I think your earlier idea is much better:

 

My favourite and - IMO - the simplest and therefore the best solution is to get rid of ""Portable.dat"". CC could focus on detecting ""Ccleaner.ini"" instead. If it exists then CC could read the settings from that file and store all new settings there. If ""Ccleaner.ini"" doesn't exist then CC should read the registry and save the settings there instead.

 

That would combine perfectly with the ""Save settings to INI file"" option. Selecting this option in v2.30 copies all relevant registry settings to ""Ccleaner.ini"" and removes them from the registry as well. De-selecting that option copies that information from ""Ccleaner.ini" to the registry and deletes that file. So, then there's no chance anymore of having two sets of contradictory information.

This one would be simple for both developers and users, and do so without forcing all installations into being poorly behaved. In the history of Windows, the registry was a replacement for the use of .ini files, so there shouldn't be any reason a non-portable installation would need to have a ccleaner.ini around. It might as well be the portable installation flag that the .exe looks for as soon as it starts.

 

And a "Run at startup" option should really be disabled and ghosted in a portable installation of any program.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.