Re: The sad state of locking -> it almost works

[Sergey Poznyakoff]

> Sam writes in the previous message in the thread that you can't switch
> from a dotlock to a kernel lock and expect it to work.  I think it
> makes sense it wouldn't; I'm not sure why it would make sense to
> switch lock types in the middle of some operation.

It wasn't actually a switch to another locking method. It was simply an
heuristic aimed to avoid trying to create a file in a non-writable
directory: an operation that would fail anyway.

> The UW-IMAP documentation talks about locking at length, and you can
> read what they have to say here:
> 
>   http://www.washington.edu/imap/documentation/locking.txt.html

Thanks for the link. This is really very useful information. By the way,
it confirms my viewpoint about kernel locking, to wit (page 14 of the
document):

"      (2) c-client applies a shared flock() to the mail file whenever"
" it reads from the mail file, and an exclusive flock() whenever it"
" writes to the mail file.  This lock is freed as soon as it finishes"
" reading.  The purpose of this lock is to prevent against unfavorable"
" interactions with mail delivery.
 [...]
"         lock (2) is the only one that works on sites that protect"
" /usr/spool/mail against unprivileged file creation.  Prudent mail"
" delivery daemons use both forms of locking, and of course so does"

Opinions?

Regards,
Sergey