Bug 6518 - emacs gets confused by normal .# files in directories
emacs gets confused by normal .# files in directories
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: emacs (Show other bugs)
6.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-29 17:26 EDT by sa
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-02-16 10:20:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description sa 1999-10-29 17:26:41 EDT
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.
Comment 1 Jonathan Kamens 1999-12-24 12:26:59 EST
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.
Comment 2 Preston Brown 2000-02-16 10:20:59 EST
this is fixed in 20.5 (next release, RHL 6.2).

Note You need to log in before you can comment on or make changes to this bug.