Re: emacsclient and "nonexistent symlinks"

[Kevin Rodgers <kevin.d.rodgers@gmail.com>]

On 3/8/11 3:17 PM, Evans Winner wrote:
> I have been doing some testing with Emacs lately and I use
> it in daemon mode and connect remotely using emacsclient.
> This has caused me to use M-x kill-emacs quite a bit and I
> think it is this which is causing me to sometimes get files
> in my filesystem that look like this in dired:
>
> .#.bbdb ->  thorne@braintron.24188:1298889269
>
> If I hit RET on one of these in dired I get a message that
> says "File is a symlink to a nonexistent target".
>
> I am wondering several things: what are they? how do they
> get there? is there something I should be doing differently?

See the "Interlocking" node of the Emacs manual (aka the "Protection against 
Simultaneous Editing" section):

    When you make the first modification in an Emacs buffer that is
visiting a file, Emacs records that the file is "locked" by you.  (It
does this by creating a specially-named symbolic link in the same
directory.)  Emacs removes the lock when you save the changes.  The
idea is that the file is locked whenever an Emacs buffer visiting it
has unsaved changes.
...
    If Emacs or the operating system crashes, this may leave behind lock
files which are stale, so you may occasionally get warnings about
spurious collisions.  When you determine that the collision is spurious,
just use `p' to tell Emacs to go ahead anyway.

> And more importantly at the moment, is there a way to
> predicate on whether a file is one of these things?  I know
> there is `file-symlink-p' that will tell me it is a symlink,
> but is there a way to see if it is also one of these bogus
> synlinks?

I thought userlock.el would have the answer, but it seems that
ask-user-about-lock is not called from Lisp...

-- 
Kevin Rodgers
Denver, Colorado, USA