Why use fcntl to unlock a file before unlinking it?

[Sam Roberts]

Bonjour,

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.

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?

Thanks,
Sam


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

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