🚀 go-pugleaf

ranjit@eniac.seas.upenn.edu.UUCP (Ranjit Bhatnagar) wrote:
> What is the appropriate behavior for Examine/ExNext if the contents
> of a directory change between one request and the next?

This is a problem I've been dealing with.  The current system does some
very strange things under certain circumstances.  Anyway, the general
rule I've gone by is that a file that is created or destroyed during an
ExNext chain may be reported zero or one times.  If files a and b are
created, in that order, it is acceptable to report b but not a.

> I have a feeling that no existing filesystem buffers the directory
> list - but how do current filesystems handle this problem, then?
> What if the directory entry last examined is deleted before ExNext
> is invoked on it?  What if the next entry (the one the hypothetical
> 'next' pointer in the previous entry) is deleted?  What if EVERYTHING
> is deleted?  

If the entry the "current" fib "points" to is deleted, the file system
is required to handle it correctly.  The current FS's just read the
block anyway.  If it hasn't been reallocated, its next pointer will
still be intact.  If it has been reallocated, the old FS follows its
next pointer anyway, resulting in a very confused directory listing.
The FFS notices if something has gone wrong, and tries to do something
sane.  It does not always succeed.

The next pointer is not stored in the fib; it only exists on disk, and is
always (or at least whenever another process can examine it) correct.

If everything is deleted, ExNext() may return information about
no-longer-extant files, but will probably return ERROR_NO_MORE-ENTRIES.

> The only solution I can think of is to search the entire directory
> every time its datestamp changes, and skip all those files which we've
> already seen.  I suppose that it's possible to do an ExNext on a
> directory entry that not only doesn't exist, but never did, because
> the filesystem must assume that it did exist at some time.  

Well, how do you skip them?  Is there an order imposed on the entries?
I'm having fun becasue I can't do that in my filesystem.  Anyway,
ExNext() may be passed anything that may have ever been returned by
an Examine() of the lock or by an ExNext() on the same lock.

A few notes: apparently, there exists a wildcard-matching utility that
unlocks a directory between calls to ExNext().  THIS IS A BAD THING.
The FFS has (and my filesystem will have) kludges to make this work
most of the time, but people who do this are EVIL.  The kludges slow
things down dramatically (when they're invoked).

The standard way to maintain more state information than you can fit into
a FIB is to add it to the accompanying lock.  When the lock is UnLock()ed,
you can throw away the state.  Thus, it is considered good practice to
UnLock a lock after you're done ExNext()ing on it.  This is usually easy,
but if you're ExNext()ing a long-term lock of yours, please DupLock()
it beforehand.

Thusm the Posix opendir corresponds to Lock() or DupLock() and Examine(),
readdir() corresponds to ExNext(), and closedir() corresponds to UnLock().

Other information: FFS can't cope well with more than one ExNext() chain
scanning a single lock.  I don't like this (I'm going to fix it in my FS),
bit it's something to keep in mind.

Does anyone have any opinions on what a directory scanning system *should* do?
Do you mind if I completely ignore files created since the first ExNext() of
a chain?
-- 
	-Colin (uunet!microsoft!w-colinp)

"Don't listen to me.  I never do."