[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The sad state of locking -> it almost works
From: |
Sergey Poznyakoff |
Subject: |
Re: The sad state of locking -> it almost works |
Date: |
Fri, 12 Apr 2002 16:30:34 +0300 |
> 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
Re: The sad state of locking -> it almost works, Sam Roberts, 2002/04/12