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