@
EricB:
Unfortunately filesize won't help at all - when you add a plugin on totalcmd.net, the author can fill in any size given in KB
(so its not detected automatically), and they usually
(as I do) give the whole downloadable package's size, which differs from the size of the main wfx/wlx/etc only in itself - thus filesize is definitely out of the game.
Date
(last modification date) is currently actively being used when comparing local file versions with the latest ones (in case TU finds newer version on the net from a given plugin), but date alone is not a trustworthy method to decide if an addon is updatable or not. Two reasons:
(the evident one is that) last modification date can easily be overwritten by the user with a single click / by various OS calls in given situations / by a virus scanner etc, and the second reason is that in many cases, a developer compiles the project on a day (e.g. on Feb 20, but decides to make it public on totalcmd.net only one / two or more days later) [there are plugins on totalcmd.net which local file modificiation date is 2005.02.27, while it has been uploaded/updated on totalcmd.net on 2010.01.30 -
cabwcx).
_________________
Maybe some of you are actually wondering / thinking about how Total Updater works to do its tasks, so I decided to explain it as simple as possible
(and with the aim to try not to be extremely boring 
):
01) It detects the files based on the found (or given) wincmd.ini - nothing magic here
02) Then TU tries to detect each plugin's version number based on:
a) the FileVersion field(s) - not an easy task, since many of the developers
(respect for the exemptions) forgets to fill out / keep updating the FileVersion field(s) embedded into the PE (executable/dll) files.
Or even 'better', on this picture you can show you a totally general situation:
image - as you can see, TotalUpdater always choose the latest found versioninfo from the PE file's sections
(when it is possible, since the StringFileInfo field can contain any other garbage strings, and often devs put in texts like "0.5.4 BETA PRO" (image) or "TC plugin 1.3" etc (TU can handle these cases too)...
b) the readme/history/etc files: so the main algorithm failed and we didn't find any usable versioninfo in any section of the PE file -> lets try to use the intelligent version detection algorithm
(if its not disabled by the user): it's going to search the actual plugin's directory for the following files
(in order):
- *history*.txt
- *history*.htm*
- *readme*en*.txt
- *read*me*.txt
- *read*me*.en*
- *read*me*.ru*
- {filename}*.txt
If any file has been found, it places them in descending order
(by last modification date) in an internal list, and uses the first one to get the versioninfo from (later I may check all the files in the given directory for version informations, and compare them with each other -
however this could slowdown the app a lot, in case of many installed utils/plugins without verinfo & with a lot readme/history etc files). E.g. for me it loads
95 items into the list with intelligent version detection off; by enabling it, this number raises to
112 (in total only 6 items are filtered out totally from my list, because of the absence of any valid version information).
03) In case we have found any usable version information using any method, we are going to compare the queried online version with it
(by using some tricks, 'cause thats not that simple either - why should it be... 
). A general VS_VERSION_INFO/
FileVersion field can
only contain numbers and dots - while an online version can contain absolutely
anything, which the author thinks would just look so fine & cool. So when a version is "1.0.0.2" in a given file, the author may have filled the online version with a following string: 1.0.2 Extreme Edition.
(unfortunately it is really a general thing, I often see plugins with such version numbering).
TU is
still able to handle it, and in such cases just assumes that they are in fact the same versions
(compares them by removing dots and zeros); yeah, in fact they should never be the same
(1.0.2 should be a newer version that 1.0.0.2), but generally we just assume that such thing doesn't happens often when the local version is SO similar to the online version
(and it is really a rare case, actually none of my installed matches this special condition). So far so good.
04) If the online version seems to be newer, lets do some extra datecheck
(if its not disabled) to avoid false alarms: now we are going to assume that the publication day is
always one day after the compile
(last modification) date: of course it isn't true in all cases, but will not cause any problem, since in general, the plugins that can be found on totalcmd.net aren't updated daily (you can modify PubDateDiffCorr=1 to any value, or completely turn this extra compare off by setting UpdateDateCheck=False inside [Plugins] section of TotalUpdater.ini) - however its not recommended as its pretty useful, and disabling it results in more false alarms.
05) If the online version still seems to be newer, lets check it in the OverridePlugVer section of the utility's config file: if its found, and the CRC32 value in the config file still matches the actual local file's CRC32 value, display it as "OK." in the list, instead of an updatable item - and this is the actual end of the comparement task.
Regards,
Bluestar
One thing which just came into my mind: please check if you have a "wincmd.ini" file in your Windows directory or not. In case no registry entries exists & TU finds it, it is going to be used instead of the one in Total Commander's default directory.
And does the problem persists if you run Total Updater directly from Total Commander (so it can catch its %COMMANDER_INI% environment variable)?
- when I wrote earlier:
