Date: Sat, 14 Jan 2006 21:59:20 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Stat(2) trigger on-demand virus scan
Message-ID: <20060115025920.GA22099@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
References: <43C9AF7B DOT 5000601 AT earthlink DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43C9AF7B.5000601@earthlink.net>
User-Agent: Mutt/1.5.11
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

On Sat, Jan 14, 2006 at 09:12:11PM -0500, Paul McFerrin wrote:
>Brett Serkez wrote:
>>> From what I've been seeing, I'm starting to suspect that the problem(s)
>>is there in both cases, the scanner simply makes it much more
>>noticable.  I do see more CPU consumption that I woud have expected
>>even without the virus scanner and the original poster's calling out
>>stat was most interesting.
>
>Interesting observation......  I just assummed it was the stat(2) call
>since the only thing I was doing was a "find ...  >file".  I know that
>find (or at least the SysV version) does a readdir(3) syscall and I
>just totally ignored it.  Even it it was readdir(3), MS should not be
>triggering on-demand scanner hooks for directory-only operations.

I'd suggest taking a look at the source code before drawing any
conclusions about what should or shouldn't be happening.

stat() is, and always has been, a complicated function.  readdir() isn't
quite as complicated but it is not just a trivial wrapper around a
windows function.  Very little in cygwin is that trivial and assuming
that things are that simple will certainly lead you to draw faulty
conclusions.

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/