This is the mail archive of the
mailing list for the Cygwin project.
RE: stat(2) triggers on-demand virus scan
- From: "Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>
- To: <Cygwin at Cygwin dot com>
- Date: Sun, 15 Jan 2006 00:11:51 -0600
- Subject: 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
Gary R. Van Sickle
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html