On Mon, Jan 16, 2006 at 10:42:10PM -0600, * * wrote:
>On 1/15/06, Christopher Faylor <[EMAIL PROTECTED]> 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 concessio
On 1/15/06, Christopher Faylor <[EMAIL PROTECTED]> 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
> perf
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
>>>
pmcferrin wrote:
> Here is something a little OT
>
> When making comparisons between multiple runs to run timing tests
> before and after a change, it there a way I can guarantee more
> consistent results? e.g. Condider the following:
>
> time find . -print | wc -l
>
> I can run the abov
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
> From: Brett Serkez
> Sent: Saturday, January 14, 2006 3:19 PM
> To: cygwin@cygwin.com; cygwin@cygwin.com
> Subject: Re: stat(2) triggers on-demand virus scan
>
> > On Sat, Jan 14, 2006 at 03:35:17PM -0500, Brett Serkez wrote:
> > >I'm still researching, I was
> From: Paul McFerrin
> Sent: Saturday, January 14, 2006 5:19 PM
> To: Cygwin@Cygwin.com
> Subject: Re: stat(2) triggers on-demand virus scan
>
> Boy did I open a can of worms!
>
No, it's like this on a regular, periodic basis.
> When I looked at the source of C
[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
Boy did I open a can of worms!
When I looked at the source of Cygwin1.dll a few years ago at the time, the stat(2)
basically called a MS API function to retreive the information and then did a simpe return.
I think it the faulty design of MS not to privide a function to get status information
[snip]
> We are not going to visit the slippery slope of adding code to Cygwin
> to work around other third party software.
I'm hoping and assuming it is going to be more a matter of making minor
changes, if it requires a major change, then it is more likely Microsoft
or some other vendor is at f
On Sat, Jan 14, 2006 at 04:18:43PM -0500, Brett Serkez wrote:
>>On Sat, Jan 14, 2006 at 03:35:17PM -0500, Brett Serkez wrote:
>>>I'm still researching, I was going to respond this is posting at a
>>>later time with more insight, but before things get out-of-hand, I
>>>wanted to jump in. I suppose
Brett Serkez wrote:
On Sat, Jan 14, 2006 at 03:35:17PM -0500, Brett Serkez wrote:
I'm still researching, I was going to respond this is posting at a
later time with more insight, but before things get out-of-hand, I
wanted to jump in. I suppose I'm still hopeful that we can zero in
on what pre
> On Sat, Jan 14, 2006 at 03:35:17PM -0500, Brett Serkez wrote:
> >I'm still researching, I was going to respond this is posting at a
> >later time with more insight, but before things get out-of-hand, I
> >wanted to jump in. I suppose I'm still hopeful that we can zero in
> >on what precisely is
On Sat, Jan 14, 2006 at 03:35:17PM -0500, Brett Serkez wrote:
>I'm still researching, I was going to respond this is posting at a
>later time with more insight, but before things get out-of-hand, I
>wanted to jump in. I suppose I'm still hopeful that we can zero in
>on what precisely is causing th
> > The stat(2) system call runs very slowly because it is constantlt
> > triggering the McAfee on-demand virus scanner to scan the file that
> > is being stat'ed. This may not seem like a big thing but I
> > frequently stat thousands of files at a batch. I find that the stat
> > runs much faster
pmcferrin wrote:
> The stat(2) system call runs very slowly because it is constantlt
> triggering the McAfee on-demand virus scanner to scan the file that
> is being stat'ed. This may not seem like a big thing but I frequently
> stat thousands of files at a batch. I find that the stat runs much
>
On Sat, Jan 14, 2006 at 12:56:11AM -0500, Paul McFerrin wrote:
>I have an "antique" question.
>
>I'm currently running cygwin.dll version: 1.3.6 ! (don't laugh). I use
>cygwin daily in my work and I'm happy not to disturb things that are not
>broken.
>
>The stat(2) system call runs very slowly
I have an "antique" question.
I'm currently running cygwin.dll version: 1.3.6 ! (don't laugh). I use cygwin daily in my
work and I'm happy not to disturb things that are not broken.
The stat(2) system call runs very slowly because it is constantlt triggering the McAfee
on-demand virus scan
18 matches
Mail list logo
