At the AFS Hackathon there was an active discussion of these issues. Here is a summary of what was concluded:
(1) The file server will advertise a capability flag indicating that
write-lock access is controlled by the same access rules as
writing to the files. ('w' or 'i' bits)
(2) It was agreed that the desired granularity for advertising the
locking sanity of ACLs is at the directory level. This sanity
value will be communicated by the file server to the cache
manager within a future revision to the FetchStatus RPC data
structure. The sanity value will indicate that the 'k' bit is
intentionally set or not set with knowledge of the implications for
applications which require the ability to obtain a read-lock before
the file can be opened for reading or executing.
It was also agreed that it is inappropriate to revise the
FetchStatus RPC just for the locking sanity value. In the meantime,
the file servers will support a runtime switch which will cause
a capability flag to be set indicating that the ACLs on all served
directories are sane. This is intended to be used by sites that
have always applied sane ACLs.
(3) The Windows clients will support the following locally controlled
locking policies:
(3a) [default]
Never obtain locks if the volume is RO.
Obtain locks if the volume is RW and ignore read-lock access
denied errors if the user's rights are no better than 'rl' and the
ACLs are not sane.
(3b) Never obtain read or write locks. (In other words, support the
old Windows AFS client behavior.)
(3c) Never obtain locks if the volume is RO and always treat the ACLs
as sane.
(4) The file server will implement a revised SetLock RPC which supports
(4a) Non-blocking lock upgrades from read-lock to write-lock
(4b) Lock downgrades from write-lock to read-lock
(4c) Will not utilizes error codes in ambiguous ways.
(5) The client ExtendLock behavior should be altered to pay attention to
EINVAL errors when renewing lock lifetimes. On Windows, the clients
will following the CIFS behavior and invalidate the file handles.
On Unix clients, the clients will stop attempting to extend the
lock. However, on Unix there is no error that can be returned to
the application.
(6) In order to support more intelligent lock handling, the file server
needs to track which client the lock was issued to.
Jeffrey Altman (on behalf of the hackathon attendees)
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
