[EMAIL PROTECTED] wrote: >>You have "ClamAV devel-20050725" build and packaged from <a >>href="http://www.sosdg.org,">www.sosdg.org,</a> so you >>have a package that includes _some_ Cygwin DLL (version?) and, as you have >>shown: it doesn't work sometimes! > > Why is that so, if you run a system without cygwin installed and install the > package then it should work fine out of the box, right?
Yes it should work. My point was, they took a CVS snapshot to compile their version of clamav, was that snapshot stable? In other words, a released version is considered stable, a CVS snapshot is not... of course this is not an absolute fact. The same goes for the Cygwin dll they included in the installer, was it really stable? Cygwin is (in)famous for releasing without testing first, so their releases are never to be considered stable (unless you think that after some time and no complaints it is stable). >>Two possible problems: was the CVS version stable? was the Cygwin DLL stable? >>(I >>'m not going to discuss the quality of their distribution, I just don't use >>it >>and I didn't like it when I evaluated it for a server). > > > So the distributed ClamAV package/cygwin DLL is the real problem. It probably is. I have not tested both, the sosdg package and Cygwin's package, so I cannot be sure. >>No, the way you write a path is not significant for Cygwin (it is translated >>internally by the dll). What may be significant is how the drive is mounted, >>file permissions/ownership, if this is a "network drive"... But you wont be >>able to see those details if you dont have Cygwin installed. > > > So why makes it a difference, if I pass the cygwin path to ClamAV instead of > passing the path in the windows style. The QuickStart document suggests 4 > ways to pass a path to ClamAV and only when passing the cygwin-style it > doesn't find the virus. > So if it were a mounting/permission problem and it makes no difference which > style of naming I use for the path, why does it fail in one case, but not in > the other cases. I don't understand this... > And it's not a network drive, it's on the harddisk in the computer, the file > can be accessed by anybody and I am administrator with all rights on that > system. > > >>Conclusion: There is something wrong with your environment. > > > You draw the conclusion from what facts!? That ClamAV is reporting different > results in a case where it does the same. The facts show something that shouldn't be happening, that's why I say that there is something wrong with your environment. What is wrong? I don't know, but there are only a few possibilities. >>Recomendation: Try the Cygwin package. > > > So you are saying the win32 version won't run out of the box? The package > distrubted is useless, because you need the whole cygwin stuff installed and > not just a few DLLs? No, the package obviously runs out of the box. You don't need to install Cygwin. > I don't get it...makes no sense to me... What I said was that having Cygwin installed (and watch out for dll problems if you have more than one version of the dll installed and in the path) will allow you two things: First: you can test if the package distributed with Cygwin has the same problem. So you can discard that your original package was flawed, or not. Second: you will be able to investigate the origin of the problem (if it's still there). For completeness, let me try to test what you did with clamav that came from Cygwin: $ clamscan c:\\tmp ... c:\tmp/Happy99.exe.virus_: Trojan.Happy99.SKA FOUND $ pushd /c/tmp $ clamscan ... /c/tmp/Happy99.exe.virus_: Trojan.Happy99.SKA FOUND See, there is no difference. (Note: my cygpath has been changed from /cygdrive to /, that's why you see the path as /c/tmp/... and not as /cygdrive/c/...) HTH -- René Berber _______________________________________________ http://lurker.clamav.net/list/clamav-users.html