Bill Landry wrote: [ ... ]
You are preaching to the choir here, as you have no argument from me. I raised the same issue the last time this happened to me a few weeks ago and clamd died twice on me in one day. The script work-around to check the databases before implementing them has saved my bacon with this last string of corrupted databases from MSRBL. However, I still agree that clamd should be able to handle these kinds of issues gracefully, and in the alternative, should not simply die silently.
Agreed-- it would be nice if clamd was more robust, either by continuing to run with the other DBs (as available) and either drop the bad line or the entire bad DB file, until a new update comes along which is OK.
However, improving how clamd responds to a bad DB is solving a consequence or symptom rather than the original problem. Maybe we should try to persuade the MSRBL site (and others) to use a similar checking script when pushing new versions of the DB's out, rather than checking upon receipt after people have used bandwidth to download and then have to discard a bad update...?
Doesn't the main ClamAV database get tested before going out? Is there some kind of run against a big collection of "known-good" files which should scan cleanly to detect a DB which contains a false positive?
-- -Chuck _______________________________________________ Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net http://lurker.clamav.net/list/clamav-users.html
