Message-ID: <2e59e6970601162042m3a789e1coaaf7fcf5d613a3@mail.gmail.com>
Date: Mon, 16 Jan 2006 22:42:10 -0600
From: * * <richardvoigt AT gmail DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: stat(2) triggers on-demand virus scan
In-Reply-To: <20060115192539.GA24554@trixie.casa.cgf.cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
References: <20060114221213 DOT GC9302 AT trixie DOT casa DOT cgf DOT cx> 	 <002401c61995$c9b54740$020aa8c0 AT DFW5RB41> 	 <20060115192539 DOT GA24554 AT trixie DOT casa DOT cgf DOT cx>
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
Content-Transfer-Encoding: 8bit

On 1/15/06, Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT 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.

>
> 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  (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.

Since cygwin is an abstraction layer, "what is presented to programs"
need not change at all.

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