GNU bug report logs - #1433
filename coding systems and w32-*-file-name functions

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1433 in the body.
You can then email your comments to 1433 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at quiet <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: quiet <at> debbugs.gnu.org
Subject: filename coding systems and w32-*-file-name functions
Date: Wed, 26 Nov 2008 15:38:00 +0100

Package: emacs,w32
X-Debbugs-CC: jasonr <at> gnu.org


---------- Forwarded message ----------
From: Juanma Barranquero <lekktu <at> gmail.com>
Date: Tue, Nov 25, 2008 at 02:38
Subject: filename coding systems and w32-*-file-name functions
To: Emacs Devel <emacs-devel <at> gnu.org>


Is this to be expected (I don't think so) or should I file a bug report?

ELISP> temporary-file-directory
"c:/DOCUME~1/Juanma/CONFIG~1/Temp/"

ELISP> (w32-long-file-name temporary-file-directory)
"c:/Documents and Settings/Juanma/Configuraci\363n local/Temp/"

ELISP> (decode-coding-string (w32-long-file-name
temporary-file-directory) file-name-coding-system)
#("c:/Documents and Settings/Juanma/Configuración local/Temp/" 0 58
 (charset windows-1252))                 ;;; this one is the correct name

ELISP> (let ((dir (read-directory-name "Dir: ")))    ;;; c:/acción
        (list dir
              (w32-short-file-name dir)
              (w32-long-file-name dir)))
("c:/acción/" nil nil)

ELISP> (let ((dir (read-directory-name "Dir: ")))    ;;; c:/accion
        (list dir
              (w32-short-file-name dir)
              (w32-long-file-name dir)))
("c:/accion/" "c:/accion/" "c:/accion/")

So it seems like w32-(long|short)-file-name have issues with coding
systems and should use (default-)file-name-coding-system.

            Juanma

---------------------------------------

This happens in 22.X too (I haven't checked older Emacsen).

The following patch fixes it, though I'm puzzled by a few things:

 - In w32-long-file-name, I'm building a string, decoding it, and then
   building another string out of the first one's SDATA, because with
   the simpler

     return DECODE_FILE (build_string (longname));

   the function returns

      #("c:/acción/" 0 10
        (charset windows-1252))

   which is a bit weird (though it's the same output from

     (decode-coding-string (encode-coding-string "c:/acción" 'cp1252) 'cp1252)

   so it is perhaps right.

 - I've read comments stating that ENCODE_FILE and DECODE_FILE can trigger a
   GC, but I've checked every use of them in the sources and got the feeling
   that sometimes Lisp_Object's are protected and sometimes not; so I'm
   thoroughly confused. In any case, I think there's no need of GCPRO
   anything in these two functions.

Comments?

   Juanma



Index: src/w32proc.c
===================================================================
RCS file: /sources/emacs/emacs/src/w32proc.c,v
retrieving revision 1.84
diff -u -2 -b -r1.84 w32proc.c
--- src/w32proc.c	22 Jul 2008 15:28:21 -0000	1.84
+++ src/w32proc.c	26 Nov 2008 12:51:37 -0000
@@ -64,4 +64,5 @@
 #include "w32term.h"
 #include "dispextern.h"		/* for xstrcasecmp */
+#include "coding.h"

 #define RVA_TO_PTR(var,section,filedata) \
@@ -1782,5 +1783,5 @@

   /* luckily, this returns the short version of each element in the path.  */
-  if (GetShortPathName (SDATA (filename), shortname, MAX_PATH) == 0)
+  if (GetShortPathName (SDATA (ENCODE_FILE (filename)), shortname,
MAX_PATH) == 0)
     return Qnil;

@@ -1811,5 +1812,5 @@
   filename = Fexpand_file_name (filename, Qnil);

-  if (!w32_get_long_filename (SDATA (filename), longname, MAX_PATH))
+  if (!w32_get_long_filename (SDATA (ENCODE_FILE (filename)),
longname, MAX_PATH))
     return Qnil;

@@ -1822,5 +1823,7 @@
     longname[2] = '\0';

-  return build_string (longname);
+  filename = DECODE_FILE (build_string (longname));
+
+  return build_string (SDATA (filename));
 }

Message #10 received at 1433-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: 1433-done <at> debbugs.gnu.org
Date: Sat, 29 Nov 2008 19:40:18 +0100

Fixed.

http://cvs.savannah.gnu.org/viewcvs/emacs/src/ChangeLog?cvsroot=emacs&r1=1.7132&r2=1.7133
http://cvs.savannah.gnu.org/viewcvs/emacs/src/w32proc.c?cvsroot=emacs&r1=1.84&r2=1.85

Previous Next

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