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

[Sam Roberts]

Last call, I'm going to snip the code if nobody can
think of a reason for it.

Cheers,
Sam

Quoting Alain Magloire <address@hidden>, who wrote:
> > Bonjour,
> 
> 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!)