[OpenAFS-devel] Re: [OpenAFS] namei interface lockf buggy on Solaris (and probably HP-UX and AIX)

[Robert Banz]

On Sep 13, 2006, at 16:51, Marcus Watts wrote:

> Robert Banz <banz@umbc.edu> writes:
> ...
>> Here's my take on the lockf stuff switching to fcntl locking...  Only
>> bothered to emulate F_LOCK & F_ULOCK because, well, that's all
>> namei_ops uses.  I've tested it on sunx86_510, it seems to be doing
>> it's thing.
> ...
>> + #define lockf(a,b,c) fcntl_lockf_emulator(a,b,c)
>> + int fcntl_lockf_emulator ( int fd, int function, off_t size ) {
> ...
>> +     return fcntl( fd, op, &fl );
>
> Uhhhh.  I think you've just recreated the "flock.o" that's in libc,  
> +/-
> naming & feature support.  Have you tried it in conjunction with
> close()?  I believe you'll find that fcntl locking has exactly the  
> same
> behavior as lockf, insofar as its interaction with close() goes.

Yeah, it's pretty much flock(), but for testing/development it was  
easier to do something like this than 'fix' the handful of places  
that lockf() is currently in use.  But it sets the beginning of the  
lock to '0' without seek()ing around to do it, which is probably a  
good thing.

WRT the close problem...  I've read Tom's post on the subject, and,  
it's potentially an issue, but from what I see it's really a separate  
problem than the seek-position-caused one...  Now, the question is  
how to go about dealing with it?  Yuk, it's making my brain melt.

-rob