[OpenAFS] set client to refuse byte-range locks?

[Marcus Watts]

Matt had replied to Adam:
> Adam,
> 
> There is work ongoing to improve the Unix-like clients' locking 
> support.  At the moment, I don't think OpenAFS 1.4 or 1.5 have an easy 
> way to do (either notion you suggested of ) what you want, but, it was 
> easy to hack up a patch to do it (the first suggestion, I didn't want to 
> think about the second one). 
> 
> Matt
> 
> Adam Megacz wrote:
> > Is there any way to set the Linux OpenAFS client to simply refuse all
> > requests for byte-range locks?
> >
> > Barring that, is there a way to find out which file the message "afs:
> > byte-range lock/unlock ignored; make sure no one else is running this
> > program" refers to?
> >
> >   - a

The second part "print out which file"..."program" is not *necessarily*
hard, but not quite trivial.  It's *extremely* OS specific.  It's easy
to print out the PID, which is at least a clue.  It's nearly always
possible to print out some part of the "command".  The same thing that
would go into .ac_comm in struct acct (acct(2),acct(5)) is almost
certainly stored by the kernel somewhere.  Traditionally, this was in
u.u_comm, but in modern Unix systems, that can and usually does vary.

Printing out the file *name* is more complicated.  It *ought* to be
impossible, and indeed, it's easy to construct circumstances where
the filename(s) that might be printed would be wrong.  For instance,
some tricky cases include making hard links to a file, removing the file
while it's open, renaming it (& moving another file in its place),
or renaming a directory above.  Even though it ought to be impossible,
there are programs such as "lsof" on linux do a perfectly respectable job
of figuring out a name.  For directories, on many systems, "getcwd"
or its ilk is trying to guarantee that it's possible to unravel
at least certain path names.  On the other hand, in AFS, things get
even weirder; on the one hand, hard links for one file between
directories don't exist, on the other hand, volume mount points
are a lot more volatile.

I think the simple answer would be to print out pid & comm on
systems where this is possible.  (ie, probably everywhere but
windows where the smb layer will probably hide this for now).
It might be useful to print out the uid as well or instead
of pid.  Printing out the filename is more complicated and
almost certainly unnecessary.

				-Marcus