Date: Sun, 15 Jan 2006 14:25:40 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: stat(2) triggers on-demand virus scan
Message-ID: <20060115192539.GA24554@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <20060114221213 DOT GC9302 AT trixie DOT casa DOT cgf DOT cx> <002401c61995$c9b54740$020aa8c0 AT DFW5RB41>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <002401c61995$c9b54740$020aa8c0@DFW5RB41>
User-Agent: Mutt/1.5.11
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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.

Basically, trivial changes which involve minimal perturbation of the
code are ok.  Changes which specifically test for a broken virus scanner
are not ok.  Changes which affect what is presented to programs (pipes
vs.  mailslots) are not ok.  Of course, "trivial" is open to
interpretation but keeping in mind that I'm ok with trivial changes,
should be enough for at least a mental exercise of "will he accept this"
when someone is contemplating a patch.  If the patch is submitted with
this understanding it will be PTC.

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/