Re: Why use fcntl to unlock a file before unlinking it?

[Sam Roberts]

We need either two locker implementations (one that does
the locking, one that calls an external program), or
we need a flag so the existing locker does one or the other.

Anybody have a preference?  You'll have to call mailbox_get_locker() if you
want to change the default lock mechanism.

The mailbox will default to doing the locking itself, or to using an external
lock program (the former is backwards compatible, the latter is what all the
user side utilities should do, everything but imap4d, pop3d, and
mail.local). Clearly the utilities running as root:mail don't want to
call an external utility, but I've had to make my spool world writeable.

I'm chasing down what looks like imap4d, sieve, and mutt not locking the
mailbox correctly. In the process of looking at the locker, I realized
there's some nice things that mutt_dotlock does that mailutils doesn't, and I
needed a dotlock utility to experiment quickly with locking and unlocking to
see what's happening with mailutils and mutt, and pretty soon I'm doing
what's pretty close to a rewrite. I've always wanted to know how dotlocking
works! :-)

I'm also adding an option to make it retry. Sergey is doing this himself in
mail.local, this will allow the retry mechanism to be used by all the
utilities (that want it).

Sam

Quoting Alain Magloire <address@hidden>, who wrote:
> 8-) a` l'eau.
> 
> > I'm working on the locker code, and I'm a little baffled.
> > 
> > I can't see much purpose in using fcntl() to lock a .lock
> > file the way its being done.
> 
> ?? he!
> Probably a mistake and no one noticed, 'til now.
> 
> > The only reason I can see is that we could potentially
> > support multiple readers of the mailbox if all the readers
> > had an fcntl() readlock on the file. But, the way the code
> > is now, it fails if you didn't make the .lock file, so this
> > won't allow this.
> > 
> > And then when the file is unlocked, the locker does
> > a fnctl() unlock, then an unlink(). Why unlock a file you
> > are about to unlink? At best, it seems a waste of time,
> > at worst it seems a race condition.
> > 
> > Can somebody explain what fcntl() locking a .lock file is
> > meant to achieve?
> 
> 8-) I can get a hold of Brian who wrote the original code
> but my feeling is, this is one of those, as sergey calls them,
> "funny bugs".
> 
> > 
> > (I'm implementing the NFS-safe link() style of locking, also
> >  checks that the file you are locking exists, and you have
> >  write permissions, and a "dotlock" utility that can be
> >  setgid() mail, so I can create lock files in a spool that's
> >  root:mail 0775).
> 
> Having an external dot(un)lock utility is good idea.
> But the locking is done internally in libmailbox when need
> be, I'm not sure where is the best way to handle.
> 

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)