4uTVyZIXNN
-
Posts
5 -
Joined
-
Last visited
-
We can qualify as "junk" activities (activity files *.FIT) that have been removed from the GPS device but the Garmin Express software keep a copy for synching later with myGarmin web site. These files should not appear anymore as they have already be processed.
-
[Garmin Express no profile synch] ; Garmin Express software. Erase personal data (*.FIT or *.GPX) in order to avoid synch of pending activities with MyGarmin: https://support.garmin.com/support/searchSupport/case.faces?caseId={b2320530-05f0-11e4-eaba-000000000000} ; Created by Phil, 24-July-2015 LangSecRef=3021 Detect=HKCU\Software\Garmin\Express Default=False FileKey1=%ALLUSERSPROFILE%\Garmin\CoreService\Devices\*|*.*|RECURSE
-
CCleaner Enhancement: get file location from an *.ini file
4uTVyZIXNN replied to 4uTVyZIXNN's topic in CCleaner Suggestions
Hello Alan, I don't want to start a fire of controversy, but if I may agree that WinApp2.ini is not crystal clear, I've found some minimal description On Piriform web site that has helped me to code some minimalistic rule for enhancing CCEnhancer. http://www.piriform.com/docs/ccleaner/advanced-usage/ccleaner-ini-files/how-to-add-your-own-program-for-ccleaner-to-clean Back to XML, I'm not sure to understand your remarks (or the meaning of your remarks). I'm suggesting here to introduce a new feature to CCleaner: the indirection to find the location of some files to be purged by looking at *.ini (or XML or Registry) entries. The fact that some .Net or Java environments are no secure enough for you has nothing to do with my enhancement request. If you have a hammer, you can use it properly to mount nails or you can hit your fingers. The latter case will not forbid the usage of hammers :-) If I can agree that the previous X11 resource file and the *.ini file syntaxes are somehow "weak", I can tell quite imperatively that the XML approach is the answer for all such cases. Normally, we start to define a grammar (DTD) for a specific purpose. This grammar can be used to automatically check the syntax validity of a given XML file. If the DTD is completely done, it will be robust, if it's done approximately, it will be weak. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> ... Notice also that we can use many DTD for fully validating one XML file. There are tons of XML parsers and the usage of such parsers is most of the time not immediate from a programming point of view. Such parsers are also based on the DTD for generating the data structures. If you tell "usage of robust XML config file" is not obvious. I tell you: yes you are right. I would add, if you are a developer, not mastering XML techniques (in a wide sense) is these days definitely a weakness (whatever your programming language, Perl, Python, Java, C#, ...) Tools like Notepad++, Oxygen, Eclipse help to develop XML stuff. XML is today almost omnipresent on all systems. I hope these remarks contribute to discuss about the right points. No personal critics are intended in any way. Cheers Phil. -
CCleaner Enhancement: get file location from an *.ini file
4uTVyZIXNN replied to 4uTVyZIXNN's topic in CCleaner Suggestions
Dear all, Thanks for your answers. I miss Windows variants experience to appraise the difficulty of existing .ini files syntax dialects and variants. If I believe the following Wikipedia article updated on 14-May-2013, there are not that much notions included in *.ini files. http://en.wikipedia.org/wiki/INI_file - An implicit global section (may be wihtout [title] tag) - A possible doted notation for suggesting nested values [titel.subtitel] - A key=value scheme Note: the Windows Technet entry in references has a validity / guarantee disclaimer Based on your remarks, it seems you have met many *.ini dialects. It would be smart to document the ones you have met. Piriform may then chose to implement few dialects based on dialect appearance frequency. I don't pretend CCleaner has to cover all existing dialects, the main point here seems to cover the possibility of having indirections. The indirection makes CCleaner more general purpose and flexible, not the *.ini file on its own. I was told by .Net programmers that the current practices in .Net environments consists to use XML files (like we do in Java). A next step after *.ini files may be to specify indirect registry entries or XML file entries. Let's start "small and easy" :-) My 2c worth :-) Cheers Phil. -
Dear all, Summary: ------------ I suggest an enhancement for generalizing the usage and adaptability from CCcleaner, reading locations from an *.ini file. Detail: ------- I'm using a utility called Syncovery (given here as an example). This utility has a fix configuration file location: %ALLUSERSPROFILE%\Syncovery\Syncovery.ini In this ini file we find the effective location from log files I would like to purge: [Main] ... LogFolder=C:\ProgramData\Syncovery\Logs Enhancement suggestion: -------------------------------- It would be smart to have such an indirection: IndirectFileKey1=%ALLUSERSPROFILE%\Syncovery\Syncovery.ini;Section=Main;Key=LogFolder|*.log being "expanded" internally in CCleaner into FileKey1=C:\ProgramData\Syncovery\Logs|*.log This would translate into a full cleanup configuration: [syncovery] LangSecRef=3024 Detect=HKCU\Software\Syncovery Default=FalseIndirectFileKey1=%ALLUSERSPROFILE%\Syncovery\Syncovery.ini;Section=Main;Key=LogFolder|*.log My 2c worth :-) Cheers Phil. P.S. I haven't found any discussion in this forum related to *.ini files parsing.