Mail Archives: cygwin/2006/01/15/01:12:04
> 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/
- Raw text -