X-Spam-Check-By: sourceware.org
From: "Gary R. Van Sickle" <g DOT r DOT vansickle AT worldnet DOT att DOT net>
To: <Cygwin AT cygwin DOT com>
Subject: RE: stat(2) triggers on-demand virus scan
Date: Sun, 15 Jan 2006 00:11:51 -0600
Message-ID: <002601c6199a$93f17250$020aa8c0@DFW5RB41>
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <43C986F2.4010900@earthlink.net>
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

> From: Paul McFerrin
> Sent: Saturday, January 14, 2006 5:19 PM
> To: Cygwin AT Cygwin DOT 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 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 without triggering all 
> sorts of other OS's overhead (e.g. on-demand scanning).
> 
> If the stat(2) is following the MS SDK guidelines for POSTIX 

...um, POSIX.  It's POSIX.

> compatability, then I don't see much other attractive 
> recourse but live with MS supid design.

What Chris F. said.  Plus, while I refuse to defend the ability of MS's
Operating Systems to properly work with Disks (admittedly it's a new thing
for them), stat's definition and/or the way many programs use stat is the
real culprit here.

>  After it *is* MS.  
> Unless there is some obsolete non-POSTIX MS API that 
> retrieves this information that does not have this side 
> effect, then I'll live with it.  It does seem silly to me 
> that you can't perform a
> stat(2) without triggering side effects.  Maybe I'm too much 
> of a Unix Geru.
> 
> 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 above sequence 3 times in a row and get huge 
> differences due to OS caching and probably application 
> caching (281 secs, 11 secs, 0.8 secs respectively).  Is there 
> any known way within MS XP Pro to flush all caching other 
> than a reboot??

The short non-rant answer to that is no, there isn't.

The long non-rant answer would require a logical explanation from Microsoft
as to why their filesystem infrastructure is completely incapable of
properly handling removable media, and that is highly unlikely to be
forthcoming.

-- 
Gary R. Van Sickle
 


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