This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

I'm sorry, but IMO this is /not/ the same thing.


What CGF suggested was to implement things in the same manner as Linux - which is one of the main goals of this project - allowing gcc to behaving in non-ansi mode by default.
This would be a major undertaking, yes, as AFAICT it involves updating, creating, and generally rewriting more than a few header files in order for it to work without adversely affecting how things work now.
As for creating sparse files - imo this is better than how windows normally does it, regardless of the app in question.



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

Matter of interpretation. IMO, CGF is saying he doesn't want large quantities of complex code. A small patch that altered cygwin's behaviour in such a way so as to be more friendly towards ZA or various AV products would be more than sufficient.




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.



No, and I guess it still isn't.

Is to me.



BTW, OP: Update your 1.3.x install. It's the 21st century for God's sake.



On this I wholeheartedly agree.


--

Spinning complacently in the darkness, covered and blinded by a blanket
of little lives, false security has lulled the madness of this world
into a slumber. Wake up! An eye is upon you, staring straight down and
keenly through, seeing all that you are and everything that you will
never be. Yes, an eye is upon you, an eye ready to blink. So face
forward, with arms wide open and mind reeling. Your future has
arrived... Are you ready to go?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]