This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stat(2) triggers on-demand virus scan


Boy did I open a can of worms!

When I looked at the source of Cygwin1.dll a few years ago at the time, the stat(2) basically called a MS API function to retreive the information and then did a simpe return. I think it the faulty design of MS not to privide a function to get status information without triggering all sorts of other OS's overhead (e.g. on-demand scanning).

If the stat(2) is following the MS SDK guidelines for POSTIX compatability, then I don't see much other attractive recourse but live with MS supid design. After it *is* MS. Unless there is some obsolete non-POSTIX MS API that retrieves this information that does not have this side effect, then I'll live with it. It does seem silly to me that you can't perform a stat(2) without triggering side effects. Maybe I'm too much of a Unix Geru.

Here is something a little OT....

When making comparisons between multiple runs to run timing tests before and after a change, it there a way I can guarantee more consistent results? e.g. Condider the following:

time find . -print | wc -l

I can run the above sequence 3 times in a row and get huge differences due to OS caching and probably application caching (281 secs, 11 secs, 0.8 secs respectively). Is there any known way within MS XP Pro to flush all caching other than a reboot?? I run into similar problems when validating multiple copies of a CD-R by calculating the checksum. The first checksum is valid but I can't trust the remainder due to OS caching.

-Paul

Christopher Faylor wrote:
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/



-- 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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]