Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!apple!bionet!agate!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Standardization
Message-ID: <8810260238.AA01166@cory.Berkeley.EDU>
Date: 26 Oct 88 02:38:48 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 30

:In article <2287@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes:
:>One problem I have been struggling with somewhat with file requesters is

UUCP:{ames|pyramid}oliveb!tymix!antares!jms  (Joe Smith) Writes:
:Keeping a list of what's in a directory is great, as long as you can
:guarentee that nothing has changed the directory behind your back.  Think
:...
:This is a worth-while idea; caching a list of file names.  To make it
:workable though requires a change to AmigaDOS.  If programs kept a lock
:on the directory that the list came from, then all we need is a new
:function to tell AmigaDOS to send us a message whenever the directory
:changes.  The messsage is a signal to the program to flush its file name
:cache.

Easy!  Note these facts:

	Whenever a file in a directory is created or deleted the timestamp
	for the directory is updated.  Not when a file is modified, but
	files are usually overwritten completely (1006) when updated so 
	this isn't normally a problem.

Now, whenever you access your cached file list, simply do an Examine()
on the directory lock and see if the timestamp changed.  The filesystem
will have cached the information anyway and thus no disk accesses normally
occur.  Rescan the directory if the timestamp is different.

This doesn't work for more than one level down ... if you create a/b/c, the
timestamp for 'a' will not change, just 'b' (and the file 'c' of course).

							-Matt