🚀 go-pugleaf

acs@amdahl.UUCP (tony sumrall) says:
> In article <1903@well.UUCP> kdd@well.UUCP (Keith David Doyle) writes:
> > (B)                  ...
> > ...              I have noticed
> > a few smarter utilities lately (notably SoundScape) that read
> > the directory once the first time you invoke such a requester, and
> > keeps the list around in memory so it dosen't have to re-search
> > if you go back to the requester a second time.  Changing the
> > drive selection will still bite you though.
> 
> Couldn't this cause problems?  I mean, given the fact that my Amiga is a
> multi-tasker, I create a file which *should* be picked up for display by
> the filename requester but *won't* be picked up because the program thinks
> that it already knows what's out on the disk?

    exactly.  i have written a self-contained file requester function
based on charlie heath's getfil.o.  i was very tempted to add that
caching feature, but finally decided against it.  you don't have to
invoke multi-tasking either; one of the reasons for a file requester
is the creation of new files.  changing the drive selection is not a
problem.  my requester routine takes a "current" directory name as an
argument, so it can easily tell if a new drive/directory is involved.
more serious is the possibilty that the user has swapped disks since
the last invocation, but there are probably easy ways to detect this.
now, if we had modification datestamps on directories, and file creation
or deletion resulted in an update...

	wayne hamilton
	U of Il and US Army Corps of Engineers CERL
UUCP:	{ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton
ARPA:	hamilton%uiucuxc@a.cs.uiuc.edu	USMail:	Box 476, Urbana, IL 61801
CSNET:	hamilton%uiucuxc@uiuc.csnet	Phone:	(217)333-8703
CIS:    [73047,544]			PLink: w hamilton