This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: stat(2) triggers on-demand virus scan
On Sat, Jan 14, 2006 at 04:18:43PM -0500, Brett Serkez wrote:
>>On Sat, Jan 14, 2006 at 03:35:17PM -0500, Brett Serkez wrote:
>>>I'm still researching, I was going to respond this is posting at a
>>>later time with more insight, but before things get out-of-hand, I
>>>wanted to jump in. I suppose I'm still hopeful that we can zero in on
>>>what precisely is causing the on-demand scanners to consume so much
>>>CPU. Since Windows programs don't trigger the same level of response
>>>(or atleast they don't appear to) their must be some change that can be
>>>made.
>>
>>I just wanted to make it clear that we aren't going to be making any
>>special concessions to a product like a virus scanner which cause
>>perfectly acceptable code to misbehave. If that is the case then it is
>>a situation for the virus scanner to work out. It's not a requirement
>>that Cygwin work around things like this.
>
>Well, that is a pretty strong statement, I'd expect from a for-profit
>company run by corporate management.
This is a practical decision.
We are not going to visit the slippery slope of adding code to Cygwin to
work around other third party software. We already have more than
enough to worry about with different windows versions. Adding the
combinatorial nightmare of worrying about different windows versions *
different virus scanners is not something I'm really interested in.
Even if we did want to do this, how do we decide what software we should
make concessions for? You're using ZoneAlarm. Is that a really popular
package among windows users? If so, do we need a dedicated ZoneAlarm
specialist on staff to make sure that every change that Corinna or I
make to Cygwin does not cause problems for ZoneAlarm? How about McAfee?
Do we need someone to worry about them, too? How about sysinternals? I
think some of their software causes cygwin to behave strangely. Do we
need a Sysinternals expert?
Or do we just pay attention to the loudest voice and then pull the
concession code out of Cygwin when the voice goes away because Corinna
and I can no longer test and support it?
>ZoneLabs offical stance is that they don't support emulated
>environments. Humm... So if neither are willing to change, then what?
>I don't know Symantec's or McAfee's offical stance.
Cygwin is a program which uses standard the win32 api. The fact that
the win32 api is used to present a bash prompt is no different than
using the win32 api to present a word processor screen. Assuming that
the "emulated environment" above actually refers to Cygwin then failure
on Zonealarm's part to fix bugs that cause Cygwin's use of the windows
API to misbehave is an arbitrary distinction and a cop-out.
>As far as coding being 'perfectly acceptable', that is a matter of
>point-of- view. If it causes such behavior, is it acceptable?
It is not a matter of a point of view if code works as documented in a
virus-scanner-free environment and fails to work when a virus scanner is
installed.
However, this is a free software project so people have the ability to
inspect the source code and offer patches. If someone offers a patch to
fix problems with a virus scanner which doesn't involve any special
tests for the virus scanner, doesn't involve extra code to work around
the virus scanner, and doesn't involve doing something like, say, using
sockets instead of pipes because the virus scanner doesn't like pipes,
then, sure, we'll consider the code. Otherwise, this is what I would
call a "special concession to third party software" and I'm not
interested in littering the code with those.
Perhaps Corinna has a different opinion and will convince me otherwise
but, until that time, I just thought I would make the ground rules
clear. I thought this was obvious stuff but I guess it wasn't.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/