Re: file locked after system crash

[Kevin Rodgers <ihs_4664@yahoo.com>]

Torbjorn Hergum wrote:
 > After a system crash emacs tells me that the file I try to edit is loced
 > by another user (which happens to be myself) on another ip-address,
 > which happens because I use dhcp and do not always get the same
 > ip-address back after a reboot/crash.
 >
 > Does anyone know where the lock-files reside, so that I can delete them
 > (manually) after a crash?

 From src/filelock.c:

/* The strategy: to lock a file FN, create a symlink .#FN in FN's
    directory, with link data `user@host.pid'.  This avoids a single
    mount (== failure) point for lock files.

    When the host in the lock data is the current host, we can check if
    the pid is valid with kill.

    Otherwise, we could look at a separate file that maps hostnames to
    reboot times to see if the remote pid can possibly be valid, since we
    don't want Emacs to have to communicate via pipes or sockets or
    whatever to other processes, either locally or remotely; rms says
    that's too unreliable.  Hence the separate file, which could
    theoretically be updated by daemons running separately -- but this
    whole idea is unimplemented; in practice, at least in our
    environment, it seems such stale locks arise fairly infrequently, and
    Emacs' standard methods of dealing with clashes suffice.

    We use symlinks instead of normal files because (1) they can be
    stored more efficiently on the filesystem, since the kernel knows
    they will be small, and (2) all the info about the lock can be read
    in a single system call (readlink).  Although we could use regular
    files to be useful on old systems lacking symlinks, nowadays
    virtually all such systems are probably single-user anyway, so it
    didn't seem worth the complication.

    Similarly, we don't worry about a possible 14-character limit on
    file names, because those are all the same systems that don't have
    symlinks.

    This is compatible with the locking scheme used by Interleaf (which
    has contributed this implementation for Emacs), and was designed by
    Ethan Jacobson, Kimbo Mundy, and others.

    --karl@cs.umb.edu/karl@hq.ileaf.com.  */

And from lisp/userlock.el:

(defun ask-user-about-lock (file opponent)
   "Ask user what to do when he wants to edit FILE but it is locked by OPPONENT.
This function has a choice of three things to do:
   do (signal 'file-locked (list FILE OPPONENT))
     to refrain from editing the file
   return t (grab the lock on the file)
   return nil (edit the file even though it is locked).
You can redefine this function to choose among those three alternatives
in any way you like."

-- 
Kevin Rodgers