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.ma.us> To: emacs-pretest-bug 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.
this is fixed in 20.5 (next release, RHL 6.2).