This bug started with emacs 20.4.1 (found on rh 6.1)
Emacs does file locking by putting info in a symbolic link
whose name is .#the-filename-being-edited
If there is already a normal file with that same .# name
then emacs will get into an infinite loop and be totally
unresponsive (until that .# file is removed)
to reproduce
echo foo > aaaa
echo bar > ".#aaaa"
now edit aaaa and try to insert some characters.
emacs is wedged. start another shell and remove .#aaaa
and all is well.
the bug is pretty obvious in the C code - it expects .# file
to either not exist or to be a symbolic link.

I've submitted a fix to RMS for this, and he said he was going to incorporate it
into a future Emacs release. I don't know if he incorporated it into 20.5 (I
haven't checked). Here's the fix:
Date: Sun, 27 Jun 1999 10:17:55 -0400
From: "Jonathan I. Kamens" <jik@kamens.brookline.ma.us>
To: emacs-pretest-bug@gnu.org
Subject: Emacs hangs if lock-file isn't a symbolic link
This bug report will be sent to the Free Software Foundation,
not to your local site managers!!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.
In GNU Emacs 20.3.11.2 (i586-pc-linux-gnulibc1, X toolkit)
of Sun Jun 27 1999 on jik.shore.net
configured using `configure --prefix=/usr --with-gcc --with-pop
--with-kerberos5 --with-x --with-x-toolkit=yes'
Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:
If the lock-file name (i.e., "/path/.#original-name") exists and isn't
a symbolic link, Emacs will hang attempting to lock the file. This is
because lock_file_1 will return 0 with errno set to EEXIST, but
current_lock_owner will fail to do anything useful because it can't
read the link.
I don't know what the "correct" fix to this is, but the fixt that I
came up with is to modify fill_in_lock_file_name so that it tries to
find a lock-file name to use which either doesn't exist or is a
symbolic link.
Note: You might consider fixing this in another way, i.e,. simply
displaying an error if there's a lock file which isn't a symbolic
link. But if you do that, then I think you have to change the default
lock-file name, because there are plenty of other programs which use
the ".#" file-name prefix (including at least two which I use every
day, which is why I encountered this problem).
Here's my fix:
*** src/filelock.c 1999/06/27 13:22:32 1.1
--- src/filelock.c 1999/06/27 13:32:54
***************
*** 297,305 ****
/* Write the name of the lock file for FN into LFNAME. Length will be
! that of FN plus two more for the leading `.#' plus one for the null. */
#define MAKE_LOCK_NAME(lock, file) \
! (lock = (char *) alloca (STRING_BYTES (XSTRING (file)) + 2 + 1), \
fill_in_lock_file_name (lock, (file)))
static void
--- 297,307 ----
/* Write the name of the lock file for FN into LFNAME. Length will be
! that of FN plus two more for the leading `.#' plus 1 for the
! trailing period plus one for the digit after it plus one for the
! null. */
#define MAKE_LOCK_NAME(lock, file) \
! (lock = (char *) alloca (STRING_BYTES (XSTRING (file)) + 2 + 1 + 1 + 1), \
fill_in_lock_file_name (lock, (file)))
static void
***************
*** 308,313 ****
--- 310,317 ----
register Lisp_Object fn;
{
register char *p;
+ struct stat st;
+ int count = 0;
strcpy (lockfile, XSTRING (fn)->data);
***************
*** 320,325 ****
--- 324,341 ----
/* Insert the `.#'. */
p[1] = '.';
p[2] = '#';
+
+ p = p + strlen(p);
+
+ while ((lstat(lockfile, &st) == 0) && ! S_ISLNK(st.st_mode))
+ {
+ if (count > 9)
+ {
+ *p = '\0';
+ return;
+ }
+ sprintf(p, ".%d", count++);
+ }
}
/* Lock the lock file named LFNAME.