[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacsclient and "nonexistent symlinks"

From: Kevin Rodgers
Subject: Re: emacsclient and "nonexistent symlinks"
Date: Tue, 08 Mar 2011 19:57:26 -0700
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv: Gecko/20110303 Thunderbird/3.1.9

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 ->  address@hidden: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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]