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


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


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