bug-gnu-emacs
[Top][All Lists]
Advanced

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

Emacs bug when working with directories starting with '/:' ???


From: Thomas M. Payerle
Subject: Emacs bug when working with directories starting with '/:' ???
Date: Thu, 21 Jul 2005 17:05:15 -0400

My apologies in advance for my ignorance about emacs as I do not generally
use it, but in supporting one of my users I believe I may have uncovered a
bug in emacs, or more precisely some of the lisp code associated with it.

I have reproduced these errors on
1) A fairly standard RedHat Enterprise Linux 3.0 Advanced Server i686 system
running GNU Emacs 21.3.1 
2) A somewhat modified RH Enterprise Linux 3.0 Workstation i686 system running
GNU Emacs 21.1.1
3) A similarly modified Solaris 9 sparc system running GNU Emacs 20.6.1

I) Alleged bug #1

On system number 1, I created a directory /: , changing ownership and mode
so that I own and have write permission
ls -ld /:  
drwxrwxrwx    3 payerle  payerle      4096 Jul 21 16:23 /:
cd /:
and run (as user payerle)
emacs a.txt
and the message line at the bottom of the screen says
File not found and directory write protected

The "File not found" part is reasonable as /:/a.txt does not exist, but
the directory is clearly not write protected.

If I create the file a.txt, set mode to 777,  and repeat the emacs command, I 
get notices about the file being write protected when it is clearly not.

If I click on the option to enter debugger on error and click on the File
menu item, the following error appears
Debugger entered--Lisp error: (wrong-type-argument stringp #<buffer a.txt>)
  string-match("\\`/:" #<buffer a.txt>)
  file-name-non-special(verify-visited-file-modtime #<buffer a.txt>)
  verify-visited-file-modtime(#<buffer a.txt>)
  (not (verify-visited-file-modtime (current-buffer)))
  (or (buffer-modified-p) (not (verify-visited-file-modtime ...)))
  (and (buffer-file-name) (or (buffer-modified-p) (not ...)))
  (or revert-buffer-function revert-buffer-insert-file-contents-function (and 
(buffer-file-name) (or ... ...)))

(the above error listing is from case where a.txt exists.  A similar (I believe
identical) error occurs if a.txt does not exist).

The above has only been tested on system #1 (the only handy versions of the
other systems run AFS and /: is not as easily played with).

II) Alleged bug #2

Again on system #1, using the same /: as described above.
cd /: and mkdir temp.  Set perms, owner so
ls -ld /:/temp is
drwxrwxrwx    2 payerle  payerle      4096 Jul 21 16:23 /:/temp

cd /:/temp
now try running emacs a.txt as payerle
Emacs window opens up in something that looks normal (I think, not a regular
emacs user).  I set to enter debugger on error, and when I try to type text
in the main buffer window, the debugger pulls up with the following message:

Debugger entered--Lisp error: (wrong-type-argument stringp #<buffer a.txt>)
  string-match("\\`/:" #<buffer a.txt>)
  file-name-non-special(verify-visited-file-modtime #<buffer a.txt>)

I have seen similar issues on systems #2 and #3 above involving much longer
directory paths beginning with '/:'.  These same directories had aliases without
the '/:', and the emacs command worked as I expected in those cases. (/: is
generally a short cut for the root of the current cell on AFS systems, which
is why my user ran into the problem.  He has simply been instructed to use the
non-/: paths for now.)

Oddly enough, an old Digital Unix 4.0d alpha system running GNU Emacs 19.34.1
does not display this problem and works as I would expect.  It may, however, 
simply be the way that OS expands the /: symlink in some system calls, although
a pwd command does return the '/:' version.  But I seem to recall some issues
with that sort of thing in porting between DU40d and other OSes before.

I realize that we are not running the latest emacs versions, but I did look
quickly at the "Changes" section for recent versions and did not see anything
which seemed to be relevant to this.  I hope the above descriptions are 
detailed enough to enable you to reproduce and diagnose the problem.


Tom Payerle     
Dept of Physics                         payerle@physics.umd.edu
University of Maryland                  (301) 405-6973
College Park, MD 20742-4111             Fax: (301) 314-9525




reply via email to

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