Offline Updater binaries fail

I’m trying to configure the Offline Updater to download CIS Binaries so network CIS clients can be updated automatically (even if they require an admin logon). The signature (.CAV) files update fine, but the updater will not download the binaries. The error is as follows…

Binaries loading for catalog ‘cis/download/updates/release/inis_1003/’ failed.
Error message: An item with the same key has already been added. 27.09.2011 10:10:12

Updater is set to “detect remote clients”, the download location has populated updater GUI

Updater downloads GB’s of temp files (this must cost Comodo hugely) but the CIS

C:\Program Files\Comodo\Offline Updater\Data\cis\updates\release\inis_####

folders are not created (or populated). What gives with this Updater software.

Is there any point posting to this forum?

I really don’t understand Comodo. They produce and update their software, and yet there seems to be almost ZERO knowledge base. I really wonder why they bother. Oh well, I guess I should learn the meaning of the word “free”… And the signature updates just get bigger and bigger! “Oh! the horror.”

Having the same issue. I have also submitted a ticket 4 weeks ago with no response, any help would be appreciated!

I had the same problem (binaries and defs were not downloading), this is what worked for me in 7 easy steps :wink: :

(1) Launch the Offline Updater UI, uncheck “Auto detect remote folders”, remove those folders representing the CIS versions that your environment doesn’t support, and turn the “Auto detect” checkbox back on. This will reduce the amount of data to be downloaded to the Offline Updater.

If you aren’t sure, search these forums to determine which folders are for which versions, or just leave the remote folder list with the current list.

(2) Click the “Stop” button to stop the Offline Updater service; quit out of the Offline Updater UI

(3) Delete all temp files in c:\windows\temp that are “tmp*.tmp” (these are straggler files that have been downloaded from Comodo that never made it to the Offline Updater data folder). On both machines that stopped downloading (1 test, 1 production machine), there were well over 64K tmp*.tmp files. It’s best to delete these files from the CMD prompt instead of using Windows Explorer, they’ll delete MUCH faster that way.

(4) Delete the following folder(s) under C:\Program Files\Comodo\Offline Updater\Data:

“av” folder to force a refresh of the AV definitions
“cis_rm” folder to force a refresh of the CIS app updates (binaries)

NOTE: Use the “Program Files (x86)” path above instead of “Program files” for 64-bit OS’s

(5) Relaunch the Offline Updater service UI and click the “Start” button to restart the service

(6) [Optional] Under the Offline Updater service settings, temporarily change the “Refresh every (secs)” from the default 300 to 10 seconds. This supposedly will speed up the download process according to another post

(7) When everything is downloaded (could take a while), change the “Refresh every” back to 300 seconds. You’ll know that all the current updates are downloaded when no more new tmp*.tmp files appear in the Windows temp folder.

You can monitor the downloading of update files by refreshing the Download Logs screen or by going into the c:\windows\temp folder with Windows Explorer, viewing by detail, reverse-sorting by date and pressing F5 to refresh the screen. If things are downloading, you will see the current file (being downloaded) file size changing or new tmp files being created each time you press F5.

I’m sure there’s a more efficient way to jump-start the offline updater, but frankly I’ve already spent way too much time Googling and trying to get help from Comodo LiveSupport – they’ve attempt to be helpful but they really don’t have a clue.

Side note: I wonder if this problem may have been caused by restarting the machine that runs the Offline Updater when it in the midst of downloading new updates. So with that in mind it might be best practice to manually shut down the service prior to restarting that machine. Another possibility may be the sheer number of temp files, might there be Windows 65K limit on the number of files within a folder?

Hope this helps