Excerpts from transarc.external.info-afs: 15-May-96 Re: AMDS problem
with AFS3.4a Robert Andrew Ryan@andre (1202)
> Is there any standard rule to decide which locking system ATK should try
> to use to maintain compatibility with AFS? For example, on AIX 3 it
> seems that only lockf resulted in real locking on AFS.
Well, I'm not working in AFS myself these days, but I can suggest some
things since we face many of the same problems.
It likely depends completely on the client conventions and the AFS
client port, and the ATK (AUIS) build will be aware at least of the
client conventions. Certainly Solaris 2.x (SunOS 5.x) should use
fcntl() for the purpose, and like other SVR4-based systems, it will
require update mode (O_RDWR, "r+") for locks to work.
What's probably messy is that there's no system-independent standard for
what error code should be returned when a lock is requested in
non-blocking mode and the lock is unavailable. There's no existing
ATK/AUIS osi_XXX function to determine whether a given error code (a
value of errno after osi_ExclusiveLockNoBlock() fails) should be viewed
as arising from the failure to obtain the contended-for lock. The
``makeboth.c'' patch already referred to was to add another error code
to the set of such codes used in the makeboth.c program.
On Solaris, the fcntl() man page says that EAGAIN is what's returned if
a non-blocking lock is requested but is not available. EBADF is
returned if the file isn't opened in an adequate mode (requested write
lock but file not open for writing, or requested read lock but file not
open for reading).
Maybe the right thing to do is to build some kind of
osi_LockUnavailable(errcode) function that would be useable throughout
AUIS, where multiple errno values could be tested for.
Craig
