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