stat(2) triggers on-demand virus scan

[Paul McFerrin]

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/