Path: utzoo!attcan!uunet!wuarchive!rice!rice!sun-spots-request
From: auspex!guy@uunet.uu.net (Guy Harris)
Newsgroups: comp.sys.sun
Subject: Re: record locking with fcntl
Keywords: Miscellaneous
Message-ID: <1990Oct26.221315.18438@rice.edu>
Date: 26 Oct 90 23:10:00 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 31
Approved: Sun-Spots@rice.edu
Originator: spots@titan.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 339, message 10
X-Original-Date: 8 Oct 90 21:21:03 GMT
X-Refs:  Original: v9n338

>I did use the F_RSETLK command when trying to lock the file on the
>NFS filesystem as opposed to F_SETLK on the file that was on a
>local filesystem.

DON'T DO THAT!

To quote from the manual page for FCNTL(2V) in SunOS 4.1:

     F_RSETLK
     F_RSETLKW
     F_RGETLK       Are  used  by  the   network   lock   daemon,
                    lockd(8C), to communicate with the NFS server
                    kernel to handle locks on the NFS files.

Those are *INTERNAL INTERFACES* intended to be used *ONLY* by the lock
daemon.  They are NOT supposed to be used by any other programs.  In order
to lock a file on a remote machine, you're supposed to use the *EXACT
SAME* F_SETLK/F_SETLKW/F_GETLK calls that you use for files on the local
machine; the NFS client code on your machine will communicate with the
lock manager on the server and it will end up doing F_RSETLK calls *for*
you on *that* machine.

There is no guarantee that the F_RSETLK/F_RSETLKW/F_RGETLK calls take
arguments that, in any way, shape, or form, resemble the arguments to
F_SETLK/F_SETLKW/F_GETLK.  In fact, if they don't, this may explain why
your program is blowing up.  (There's still a bug in the SunOS kernel if
it panics; it should require a process that does the
F_RSETLK/F_RSETLKW/F_RGETLK calls to be super-user, or to have registered
itself as the lock daemon, or in some other way identify itself as having
the right to issue those calls, or alternatively should properly check the
arguments to that call and reject any that aren't valid.)