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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
