[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Sam Roberts
Subject: Re: Why use fcntl to unlock a file before unlinking it?
Date: Mon, 25 Feb 2002 20:42:45 -0500
User-agent: Mutt/1.3.16i

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


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!)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]