I HAVE been deleting all that is in db directory - it won't update.
Citing an OS authored a dozen years ago seems like clutching
at straws... I use W7 x64bit. Can this issue be escalated please?

ClamAV update process started at Sat Jul 09 12:40:07 2011
Downloading main.cvd [100%]
Downloading main.cvd [100%]
main.cvd updated (version: 53, sigs: 846214, f-level: 53, builder: sven)
Downloading daily.cvd [100%]
Downloading daily.cvd [100%]
daily.cvd updated (version: 13302, sigs: 144462, f-level: 60, builder: ccordes)
Downloading bytecode.cvd [100%]
Downloading bytecode.cvd [100%]
bytecode.cvd updated (version: 143, sigs: 40, f-level: 60, builder: edwin)
Database updated (990716 signatures) from database.clamav.net (IP: 81.91.100.173)

--------------------------------------
Completed
--------------------------------------

*FINALLY* ClamWin finds itself able to update itself.
The mirrors.dat file stays at 52bytes.
Acronis is still running.
Network is still running.
Internet connectivity is still running.

ClamWin's operation is unreliable.
Please advise.

Thought: Only C: is SSD. The remaining 7 HDDs are
electro-mechanical in a mixture of stand-alone
and RAID5. I know the SSD does background
stuff to maintain the lifetime of the cells. Would
this sort of hardware activity be affecting ClamWin?

2011-07-09 1320hrs local

Acronis is running OK (81% done backing up w/s to server).
Network runs OK.
Internet connectivity runs OK.
Server now backing itself up to a (network) NAS box OK.

ClamWin can manually update itself OK...
ClamAV update process started at Sat Jul 09 13:19:51 2011
main.cvd is up to date (version: 53, sigs: 846214, f-level: 53, builder: sven)
daily.cvd is up to date (version: 13302, sigs: 144462, f-level: 60, builder: ccordes)
bytecode.cvd is up to date (version: 143, sigs: 40, f-level: 60, builder: edwin)
--------------------------------------
Completed
--------------------------------------

mirrors.dat currently 52bytes in size.

ClamWin situation currently operational.
Everything does work 'together' right now.

At some point later ClamWin will fail to update
itself automatically and I will then find its own
mirrors.dat file quadrupled in size to 208bytes.

Please advise.

The unreliable automatic 'updating' continues...

Some of the many changes I have made to
appease this unreliability have now been
normalised in the face of a complete lack
of effectiveness. It was never THIS unreliable
in the past years, so I see no particular reason
why it should be so troublesome nowadays.

I have now also re-installed ClamWin.
The update process failed shortly afterwards.
It is pointless relating exact minute by minute
or hour by hour 'progress' until you can specify
exactly what it is that is being reported by your
ClamWin or what exactly you need to so diagnose.

The automatic hourly update has failed.
A manual reload failed and did not suceed until
the faulty mirrors.dat being written by ClamWin
itself was deleted and a manual update triggered.

Would the SUPPORT FORUM please advise how I am
to stop ClamWin from corrupting its own control file.

Since the last posting ClamWin has succeeded in auto updating
itself without issue. Fine. Lots of stuff hereabouts auto updates.
So much that it's difficult to keep track of what might or might
not be conflicting with anything else.

Over the previous hourly period ClamWin has returned
to being unsuccessful at auto updating itself. I have now
deleted all the db files (ie not just mirrors.dat).
ClamWin still won't update.

Please escalate.

Please advise.

There's a miasmatic element to all of this
...and I *WILL* get to the bottom of it.

It's timing related - not bandwidth or congestion.
Conflict or interaction with the windows tasker
and the Google task stuff (that they haven't
asked for permission to load or trigger). Don't
know how or why yet. Am working on various
stuff disabled to try and sleuth the difference.

Please advise...

I was hoping one of the developers (alch or sherpya) would see this. Did the problem start about the time we switched to daylight savings time? Seems like there have been some problems (not lately) related to time, but I don't recall the details. Again, you might search the forum posts for something like that.

Regards,

...hence my "Please escalate" mantra.


Onset too vague and iteration too variable. Earlier this year certainly;-)


Indeed. I also reported a possible NTP vector earlier but
the onset of the issue triggering was too vague/unreliable
to reliably start pointing fingers.

Router has a gang of four NTP IPs for resilience.
Have dropped this down to a single IP for clarity:
0.smeserver.pool.ntp.org
Done so similarly for the gateway server.
When the duff updating re-occurs next I will first
attempt to enforce W7 workstation syncronisation
manually and then attempt to fix ClamWin (using
the same timing source throughout ...JIC).

Have tried a considerable variation of re-use of
previous working ClamWin control files and, indeed,
of its working directory too. Found nothing consistent.
Sometimes it works sometimes it doesn't. Earlier this
evening NOTHING worked so I started disabling all
the Google-related auto-update tasks that Sentinel
has been thoughtfully flagging. I had no idea that
Google was getting this pervasive without authority.

Like I said a long while ago in this thread there's
much too much getting 'auto-updated' nowadays
but guess who is the muggins who has to sit down
and try and fix the mess when it goes pear-shaped.

Does the signature rectification take more than three weeks or am I just too impatient?

Correction of false positive signatures at Clam should normally take no more than a couple of days. Each sigmaker is responsible for correcting his own false positives, however, and the sigmaker may be away for longer. You can always email Luca at Clamav dot net and tell him if you think it is taking to long.

Regards,

Done.

Duff auto-update scenario now in force.
Re-sync'd router, server and workstation.
Update not OK.
Deleted each of the four files in .db one by one.
Update not OK.
Noticed... only thing 'major' running at the moment
is: ClamScan itself:-| It's doing its regular daily scan.
Update currently completely unsuccessful.

A few minutes later, while typing up this very trouble
report post, ClamWin auto-updates itself successfully...
and manual attempts succeed too.

ClamScan continues its regular daily scan.

Please advise.

It happened yesterday evening and again this AM.

ClamWin failed to update itself (this time post boot).
Deleted each of the four .db files in reverse order
of expectation but even with the entire directory
contents having been deleted ClamWin was unable
to be updated on command.

I left it and got on with other matters.
Within the observed 5mins retry period ClamWin
successfully AUTO-updated itself despite for want
of my trying to get it done earlier. That's the 2nd
time all manual means failed but followed by a
successful auto update retry.

...as always, please advise.

ClamWin should try to update every time it is scheduled or every time you manually do one. However, there may be no signatures to update. Clam does not do regular updates every hour. On most days, you will probably get from zero to about 10. There are no automated signatures--the sigmakers do them manually.

Regards,

Noted. You've missed my point entirely.
I am not referring to the signature authoring mechanism
nor its intermittent nature. I am referring to ClamWin's
(the application here running here at my site) inability
to either automatically or manually update itself for
any length of time (reliably).