Detecting directory changes.

[Carl Perkins]

If another way of doing it is desired, perhaps the following could
be considered.

The general description of the method is to use the lock manager in
a way that is compatible with how RMS uses it.

What you'd do is to take out a lock in PR (protected read) mode on
the RMS resource that represents the directory file. These resources
have names that are built using a known pattern (4 character prefix
of "RMS$", 6 byte FID, 16 character devlockname). So after you read
the directory data into your cache you enqueue a PR mode lock to the
resource and close the file, at which time this lock should be granted
(possible refinement - the lock could initially be requested in NL (null)
mode with LCK$M_EXPEDITE specified, then a conversion to PR mode enqueued;
this may have some advantages). You specify a blocking AST with the
lock. The PR mode lock will not block any read-only access to the file,
as they should PR (or maybe CR) mode locks. Any open allowing writes
to the file should trigger your blocking AST as these will involve a
PW (protected write) or EX (exclusive) mode lock which will be blocked
by this lock. In the blocking AST you enqueue a conversion of lock to
NL mode and set a flag for the cache indicating that it is invald. The
next time the cache is needed the program checks the validity flag and
finds that it is not valid so the cache is refreshed from disk and the
lock converted back to PR mode. (Note that the resources used by the
RMS locks all have a minimum of executive mode access and are all
system locks. This makes enqueueing them just a bit more complicated.)

The advantage is that you wouldn't need to poll the sequence number
via F11X$POSIX_FASTRDSEQNOS every time you want to read from the cache,
possibly giving some slight (possibly trivial) increase in performance.
(Instead of polling for the value, you get notified via the blocking AST.)

The disadvantage is, I think, that you had best be very carefull
when messing around with RMS or you could have an adverse effect
on the system as a whole. It is also possible that you will be
invalidating the cache more often than is really necessary since
other accesses to the directory file for reading it may not always
be done in a read-only type of way (defaults for opening files in
C, for example, is no sharing which presumably causes an EX mode
lock to be used which would trigger the blocking AST and invalidate
the cache).

You should note that the Frontport library already does this sort
of thing with RMS locks, thus Samba V2.0.6 is also already doing
this sort of thing (and it works OK). Frontport's useage of this
is, as I recall, somewhat simpler - I think it only enqueues locks
to RMS resources to find out who is blocking you, and those test
locks are immediately dequeued. This is part of its increase to
fcntl() functionality regarding locks.

It's a possibility to consider, anyway.

--- Carl