Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Delivered-To: mailing list cygwin@sources.redhat.com Date: 13 Feb 2001 14:17:56 -0500 Message-ID: <20010213191756.15822.qmail@lizard.curl.com> From: jik-cygwin@curl.com To: lhall@rfk.com CC: cygwin@cygwin.com In-reply-to: <4.3.1.2.20010213140154.019d99c8@pop.ma.ultranet.com> (lhall@rfk.com) Subject: Re: Optimizing away "ReadFile" calls when Make calls stat() References: <4.3.1.2.20010213134821.019a7130@pop.ma.ultranet.com> <4.3.1.2.20010213134821.019a7130@pop.ma.ultranet.com> <4.3.1.2.20010213140154.019d99c8@pop.ma.ultranet.com> > Date: Tue, 13 Feb 2001 14:08:58 -0500 > From: "Larry Hall (RFK Partners, Inc)" > > >1) The cache would have to be automatically invalidated whenever the > > file is changed, and you'd thus need to check if a file has changed > > before using the cache, and those checks would themselves take > > time. > > I'd submit that while this may be true in general, it shouldn't be in the > case of symbolic links and executables. These attributes don't really change > or, if they do, they change in a very defined way which should make it > possible to track. Yikes, I don't agree with that at all. Non-deterministic behavior is *much* worse than slow behavior. It would be *impossible* for Cygwin to track every single change to symbolic links and/or executable files, since people can modify such files without going through Cygwin at all (e.g., modifying them directly with a Windows app, or modifying such a file on a SAMBA mount through Linux). Since it's impossible for Cygwin to know when such files are changed out from under it, it *must* check them, or at least check if they have been changed, each time they are accessed. jik -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple