all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Thomas M. Payerle" <payerle@benfranklin.physics.umd.edu>
Cc: payerle@phys.umd.edu
Subject: Emacs bug when working with directories starting with '/:' ???
Date: Thu, 21 Jul 2005 17:05:15 -0400	[thread overview]
Message-ID: <200507212105.j6LL5Fh4004642@carnot.physics.umd.edu> (raw)

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	other threads:[~2005-07-21 21:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-21 21:05 Thomas M. Payerle [this message]
2005-07-24  0:01 ` Emacs bug when working with directories starting with '/:' ??? Richard M. Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200507212105.j6LL5Fh4004642@carnot.physics.umd.edu \
    --to=payerle@benfranklin.physics.umd.edu \
    --cc=payerle@phys.umd.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.