GNU bug report logs - #13013
24.3.50; Windows XP bug? get-file-buffer, file-name-as-directory

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jambunathan K <kjambunathan <at> gmail.com>
Cc: istazahn <at> gmail.com, 13013 <at> debbugs.gnu.org
Subject: bug#13013: 24.3.50; Windows XP bug? get-file-buffer, file-name-as-directory
Date: Tue, 27 Nov 2012 20:01:19 +0200

> From: Jambunathan K <kjambunathan <at> gmail.com>
> Date: Tue, 27 Nov 2012 22:54:57 +0530
> Cc: Ista Zahn <istazahn <at> gmail.com>
> 
> 
> This report is a digest of following thread:
>     http://www.mail-archive.com/emacs-orgmode <at> gnu.org/msg62455.html.

I will read it soon, for now replying only based on what you posted.

> The problem is because of Emacs mangling file paths like this on Windows
> XP.
> 
>     "c:/DOCUME~1/IZAHN/LOCALS~1/Temp/odt-8052VuJ/"
>     "c:/Documents and Settings/IZAHN/Local Settings/Temp/odt-8052VuJ/content.xml"

Emacs doesn't mangle file names.  Emacs uses the value of TEMP
environment variable, which Windows sets to a 8+3 alias of the long
name (evidently trying to avoid bugs in programs that don't handle
whitespace in file names).  Emacs then converts the 8+3 alias to the
full long name when it stores the file name in the buffer object of
the buffer that visits the file.

> Create a ielm buffer with 
>     M-x ielm RET
> 
> and type out the following 4 lisp forms ONE-by-ONE.
> 
>     (setq org-e-odt-zip-dir (file-name-as-directory (make-temp-file "odt-" t)))
> 
>     (with-current-buffer (find-file-noselect (concat org-e-odt-zip-dir "content.xml") t) (buffer-file-name))
> 
>     (with-current-buffer (get-file-buffer (concat org-e-odt-zip-dir "content.xml")) (save-buffer 0))
> 
>     (get-file-buffer (concat org-e-odt-zip-dir "content.xml"))

The solution is to call file-truename on

  (concat org-e-odt-zip-dir "content.xml")

Think of the 8+3 name as a symlink to the long file name.

> I am surprised that `get-file-buffer' is returning nil.

It returns nil because it compares file names with string-equal.

> Why is there a mismatch between file names as reported by
> `file-name-as-directory' and `buffer-file-name'.

See above.  Won't the same happen with symlinks?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.