Independent lockfile package.

[Rob Browning <rlb@cs.utexas.edu>]

One way or another I'd like to have a package that provides the
functionality of liblockfile on the command line, and I'd like the
package to be dynamically linked against liblockfile (so changes in
Debian locking policy remain centralized).

I know about the lockfile program in procmail, but I don't want to
require that people install procmail just to have access to a set of
command line locking programs.  As an alternative to the solution I'm
proposing below, perhaps lockfile could be split out as a separate
binary package, athough it's API is a little different from
liblockfile's, and it wouldn't be dynamically linked.

In any case, I've written a tiny wrapper program that I was going to
release as liblockfile-progs.  The binaries would be:

 mail-lock      [ -r retrycount ] [ user ]
 mail-unlock    [ user ]
 mail-touchlock [ user ]

 lockfile-create [ -r retrycount ] [ file ]
 lockfile-remove [ file ]
 lockfile-touch  [ file ]

You would use these to write scripts like the one below (note that
lockfile-touch is launched as a separate process with responsibility
for keeping the lockfile from going stale -- it just sleeps most of
the time, but wakes up to touch the lock every so often until you kill
it):

  set +e

  echo "Frobnicating mailbox..."
  mail-lock rlb
  if [ $? != 0 ]
  then
    echo "Failed to lock mailbox for frobnication."
    exit 1
  fi

  mail-touchlock rlb &
  MAIL_LOCK_FONDLER="$!"
  frobnicate-mailbox rlb
  kill "${MAIL_FONDLER}" && true
  mail-unlock rlb

  if [ $? != 0 ]
  then
    echo "Failed to unlock mailbox after frobnication"
    exit 1
  fi

As a nit, I think mailunlock(3) and touchlock(3) should have taken a
"char *user" argument since maillock(3) does.  You might want to lock
a mailbox from one process, and unlock it from another.  I can get
around this by implementing everything in terms of lockfile_remove,
etc, but it would be nice to use the functions designed for the
purpose.  Though I suspect there's probably some historical precedent
to respect.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930