It first opens a lockfile with a unique name and then links that one
to the classic /var/spool/mail/username.lock lockfile. Then it checks the
number of links on that file. If there are two then the lock is
successful. Problem is Linux fstat call always returns 1 for the number of
links even though a link() was done immediately prior.
I wonder if some kind of caching in the NFS client part of the kernel
does not properly update the inode information in this situation?
Here is the relevant part of the code that does the locking:
if (ob->use_lockfile)
{
lock_fail_type = "lock file";
hd = open(hitchname, O_WRONLY | O_CREAT | O_EXCL, ob->lockfile_mode);
if (hd < 0 && (errno != EACCES || ob->require_lockfile))
{
addr->errno = errno;
addr->message = "creating lock file hitching post";
return;
}
/* If a hitching post exists, attempt to hitch it to the lock file; get
its subsequent state, and then get rid of its name. If the hitch was
not successful, try again, having unlinked the lock file if it is too
old. */
if (hd > 0)
{
link(hitchname, lockname);
fstat(hd, &statbuf);
close(hd);
unlink(hitchname);
if (statbuf.st_nlink != 2)
{
if (ob->lockfile_timeout > 0 && stat(lockname, &statbuf) == 0 &&
now - statbuf.st_ctime > ob->lockfile_timeout)
{
DEBUG(2) debug_printf("unlinking timed-out lock file\n");
unlink(lockname);
}
continue;
}
}
}
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
PGP Public Key = FB 9B 31 21 04 1E 3A 33 C7 62 2F C0 CD 81 CA B5