Talk:ClamAV Win32
From ASSPSMTP
ClamAV Win32 without NET 2.0?
Does ClamAV require Net 2.0 for installation only or is it really required for operation?
Comments
Some versions of Windows 2003 may require "C:\Program Files\" to be entered as "C:\Progra~1\" in Clamd.conf, FreshClam.conf, and the RunClamd.ini files. --BrandywineITS
- Would you be some kind as to specify what version. I tested and verified this on multiple installs of Server 2003 Standard and have never had that problem. --Geniusfreak
You can force the boot sequence to load clamd before ASSP by adding a key of type REG_MULTI_SZ (also known as Multiple String Value) to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASSPSMTP called DependOnService set to RunClamd with regedit. --jwyde
Running the installer on Windows 2003 x64 Edition with default options creates a home directory for ClamAV under "C:\Program Files (x86)\". However, the accompanying readme states clearly that it must reside inside "C:\Program Files\" or it simply won't work. Of course, I had to install it in order to find this out --ThwartedEfforts 02:53, 8 May 2007 (MDT)
- Just discovered that the installer always uses "C:\Program Files (x86)\" regardless of which directory you ask it to use. You need to cut/copy and paste the ClamAV folder from one to the other after setup has finished --ThwartedEfforts 02:59, 8 May 2007 (MDT)
- I've run ClamAV on Windows 2003 x64 Edition for a three days now and the service has been so (a) processor hungry and (b) unreliable that I've removed it. The problem has been that whenever ClamAV screws up, and it's done so twice now without any explanation, the ASSP service gets its undergarments in a twist waiting for a response back from it. Reading through my earlier comments above, it dawned upon me just how little testing ClamAV Win32 must have had and that if you want your mail system to be reliable you'd be wise to give it the swerve --ThwartedEfforts 02:05, 11 May 2007 (MDT)
- We made some changes in the way ASSP handles Clamd not responding in the 1.3.1 release. Previously it would almost grind the system to a halt due to a locking issue(at least i *think* thats what it was causing it). It should handle it much better from the 1.3.1 release an onward. These changes were made after Fritz announced 1.3.1 so if you are running this version already re-download it from the sf.net site. That said, I'm not sure how well clamd runs on a 64bit OS, that would be a question for the w32 Clamav people. --Geniusfreak 03:48, 11 May 2007 (MDT)
- I've run ClamAV on Windows 2003 x64 Edition for a three days now and the service has been so (a) processor hungry and (b) unreliable that I've removed it. The problem has been that whenever ClamAV screws up, and it's done so twice now without any explanation, the ASSP service gets its undergarments in a twist waiting for a response back from it. Reading through my earlier comments above, it dawned upon me just how little testing ClamAV Win32 must have had and that if you want your mail system to be reliable you'd be wise to give it the swerve --ThwartedEfforts 02:05, 11 May 2007 (MDT)
File::Scan::ClamAV is not specified nor noted as not being required for the ClamAV Win32 integration. I noted today that my Windows 2003 server / ActiveState Perl deployment does not have File::Scan::ClamAV installed, and therefore isn't available to ASSP.
I think that since the *nix installs suggest installing File::Scan::ClamAV that it should be noted here that it is unnecessary (or provide direction on how to get File::Scan::ClamAV installed).
found the wiki page on how to install. Perhaps there could be simply a reference to it from this page as well.
