X-Spam-Check-By: sourceware.org Date: Tue, 17 Jan 2006 01:09:12 -0500 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: stat(2) triggers on-demand virus scan Message-ID: <20060117060911.GA28935@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> <20060115192539 DOT GA24554 AT trixie DOT casa DOT cgf DOT cx> <2e59e6970601162042m3a789e1coaaf7fcf5d613a3 AT mail DOT gmail DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2e59e6970601162042m3a789e1coaaf7fcf5d613a3@mail.gmail.com> User-Agent: Mutt/1.5.11 Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Mon, Jan 16, 2006 at 10:42:10PM -0600, * * wrote: >On 1/15/06, Christopher Faylor 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/