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
17 matches
Mail list logo
