liblockfile L_PID behavior and use of stat atime

[Rob Browning <rlb@defaultvalue.org>]

Someone reported a bug against lockfile-progs, and while investigating
I noticed a couple of things about liblockfile that didn't seem quite
right.

First of all, if you run "lockfile-create foo", which calls
lockfile_create() without the L_PID flag, you'll see that the
resulting foo.lock file contains "0\0".  If you call lockfile_create()
with L_PID, the file will contain just the PID, without a trailing
'\0'.  I suspect that this is because lockfile_create() contains a
"len = 2;" where instead it should have something like the "len =
strlen(...)"  that's used in the L_PID case.

Secondly, and possibly more significantly, it looks like
lockfile_check() may be broken under some circumstances.

If lockfile_check() is able to open, read, and stat the lock file, it
compares the lock file access time, rather than the current time, to
the modification time in order to determine whether or not the lock
file is stale.  I'm not sure why it does that, but on a filesystem
mounted with noatime I don't think that lock files created without
L_PID will ever be considered stale.

Does the above seem reasonable?  If so, I'll fix the problems and NMU.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4