From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Thomas M. Payerle" Newsgroups: gmane.emacs.bugs Subject: Emacs bug when working with directories starting with '/:' ??? Date: Thu, 21 Jul 2005 17:05:15 -0400 Message-ID: <200507212105.j6LL5Fh4004642@carnot.physics.umd.edu> NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1121981169 19293 80.91.229.2 (21 Jul 2005 21:26:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 21 Jul 2005 21:26:09 +0000 (UTC) Cc: payerle@phys.umd.edu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 21 23:26:02 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DviYF-0005T8-Bh for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Jul 2005 23:25:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DviaM-00083l-0X for geb-bug-gnu-emacs@m.gmane.org; Thu, 21 Jul 2005 17:28:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DviWs-0006d7-E5 for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2005 17:24:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DviWo-0006bQ-96 for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2005 17:24:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DviWn-0006LQ-SS for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2005 17:24:25 -0400 Original-Received: from [129.2.42.9] (helo=benfranklin.physics.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DviO3-00077j-FE for bug-gnu-emacs@gnu.org; Thu, 21 Jul 2005 17:15:23 -0400 Original-Received: from carnot.physics.umd.edu (carnot.physics.umd.edu [129.2.172.163]) by benfranklin.physics.umd.edu (8.12.10/8.12.10) with ESMTP id j6LL5Kup007920; Thu, 21 Jul 2005 17:05:20 -0400 (EDT) Original-Received: (from payerle@localhost) by carnot.physics.umd.edu (8.12.10/8.12.10) id j6LL5Fh4004642; Thu, 21 Jul 2005 17:05:15 -0400 Original-To: bug-gnu-emacs@gnu.org X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:12561 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:12561 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 #) string-match("\\`/:" #) file-name-non-special(verify-visited-file-modtime #) verify-visited-file-modtime(#) (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 #) string-match("\\`/:" #) file-name-non-special(verify-visited-file-modtime #) 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