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

[Christopher Faylor <cgf-no-personal-reply-please at cygwin dot com>]

On Mon, Jan 16, 2006 at 10:42:10PM -0600, * * wrote:
>On 1/15/06, Christopher Faylor <cgf-no-personal-reply-please@cygwin.com> wrote:
>> On Sat, Jan 14, 2006 at 11:37:33PM -0600, Gary R. Van Sickle wrote:
>> >[snip]
>> >>>>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
>> >
>> >Huh?  Has it even been 24 hours since you suggested Cygwin be changed
>> >in a non-standardized manner merely to band-aid a broken third-party
>> >IRC client?
>>
>> The fact that you have this opinion makes me think that you and other
>> people are not entirely clear on what we're supposed to be doing here
>> even though it only takes one sentence to explain things:
>>
>> We're trying to emulate linux.
>>
>> So, think about this sentence and then explain how it jives with your
>> assertion that I was trying to do something in a "non-standardized
>> manner".  How is it "non-standardized" to make cygwin emulate linux
>> more closely so that programs which build on linux are more likely to
>> build on cygwin?
>>
>> It's curious that you'd see a parallel between modifying cygwin to
>> accommodate a specific broken commerical virus scanner and modifying
>> Cygwin in such a way that more programs are likely to build with it.  I
>> don't get that at all.
>>
>> >The slope you mention has already been visited on more than one
>> >occaision.
>>
>> Sorry, but you'll have to come up with more convincing examples than the
>> ones you've used.  I'm sure that, through the years, I've probably said
>> "sorry that's the way it works" to people who've complained that cygwin
>> didn't work like linux, but my opinion has been evolving since the goal
>> of the project was changed to target a specific system (linux).  I think
>> I've made the point a few times in the last year that linux is the
>> target that cygwin is shooting for so I don't see any inconsistency here
>> at all.
>>
>> I'm fairly surprised that you're arguing this point at all.  When I saw
>> that you'd responded to this thread, I thought I'd be seeing a rant
>> about stupid virus checkers and how Cygwin shouldn't be going out of its
>> way to work with them.  I didn't expect that you'd be arguing the issue
>> (or the meta-issue) of precedent for allowing such a change.
>>
>> >And doesn't Cygwin still create sparse files for the benefit of one
>> >single third-party application?  The slope you mention has already been
>> >visited on more than one occaision.
>>
>> Cygwin creates sparse files in some situations because that's how
>> linux/unix works.  IIRC, we actually made an accommodation to windows to
>> not create sparse files as often as linux because people complained
>> about the default linux behavior.  I don't recall doing this for a
>> third-party windows application, however.  I thought we just did it
>> because linux works that way but I may be misremembering.  If the change
>> was to make a *linux* program work better then I think we're once again
>> on pretty firm ground.  We were, once again, changing things to make it
>> easier for linux programs to port without problem to Cygwin.  And, once
>> again, this is nowhere near the same thing as modifying cygwin to
>> accommodate a broken virus checker.
>>
>> >[snip]
>> >>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.
>> >
>> >Again, that last sentence is simply not a true statement, unless you
>> >want to split hairs about the "littering" part.  And I have to question
>> >the veracity of a "PTC" statement that has as its prerequisites that
>> >the patch involve no actual code.
>>
>> If you didn't get what I was saying, I'm wondering why you couldn't just
>> ask for clarification without questioning the truthfulness of what I
>> said.
>>
>> However, let me try to clarify again.  If someone found that one
>> function caused a problem but another equivalent function didn't, then
>> using the equivalent function would be ok.  If someone found that a 10
>> line test was necessary to determine if a virus scanner was running then
>> that is not something that I would want to do.  If someone found that
>> avoiding the use of pipes and using mailslots instead "fixed" things,
>> then that would not be ok.
>
>I suggest a slightly different standard:
>
>(1) NO conditionals depending on what other software is installed or running
>(2) NO weakening the linux/posix compliance
>
>If it was found that using the Win32 pipes API caused on-demand virus
>scanning but Win32 mailslots didn't, or named pipes are slow but
>unnamed pipes fast, or whatever, AND the performance improvement was
>significant (for avoiding virus scans it might be reducing CPU usage
>for such transfers by 90%), and performance in other cases was
>comparable (i.e.  no disadvantage to mailslots when there is no virus
>scanner), AND it was still possible to provide the
>linux/posix-compliant API, then yes, rewrite cygwin pipe functions so
>they transparently use Win32 mailslots underneath.  Keyword:
>transparently.  They should still be pipes as far as the cygwin program
>is concerned, just cygwin1.dll should known they are actually mailslots
>under the hood.

Please don't take my email as some change of policy.

My attempt to explain what we would accept as a work around for a buggy
virus checker does not in any way imply that we've stopped accepting the
usual patches which are intended to fix bugs or make things better.

I chose the case of mail slots vs.  pipes because I am fairly certain
that making a change like this would cause some programs to misbehave
just because of the nature of mail slots vs.  pipes.  That's why I chose
that particular example - it would not be a transparent change.

If someone submits a bug which makes things faster and also works around
a problem with a virus checker then, of course, it will be considered.
This would be basically a standard patch submission with a fortunate
side-effect.

I responded to the first message about this because I hate to see people
going down a path which will eventually lead to frustration so I thought
I should say something.  However, since it seems like I can't describe
this concept adequately enough for people to grok, let me propose
another way of doing this: If you think you've stumbled across a
technique for fixing a problem with a virus checker, send a query to
cygwin-patches with some sample code or meta-code and ask if the
technique would be considered for cygwin.  If possible, try to keep in
mind what I have mentioned for guidelines but if you're really confused
by what I said and have some code you want to show someone, then go
ahead and send it to cygwin-patches and mention that you aren't sure if
it qualifies or not.

I think this is a pretty good use of the cygwin-patches mailing list as
long as discussions are technical and demonstrate at least some grasp
of how cygwin works.

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/