bug-mailutils
[Top][All Lists]
Advanced

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

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


From: Alain Magloire
Subject: Re: Why use fcntl to unlock a file before unlinking it?
Date: Sun, 24 Feb 2002 13:13:04 -0500 (EST)

> 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.




reply via email to

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