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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (Emacs bug Tracking System)
To: "Juanma Barranquero" <lekktu <at> gmail.com>
Subject: bug#1433 closed by "Juanma Barranquero" <lekktu <at> gmail.com> ()

[Message part 1 (text/plain, inline)]

This is an automatic notification regarding your bug report
which was filed against the emacs,w32 package:

#1433: filename coding systems and w32-*-file-name functions

It has been closed by "Juanma Barranquero" <lekktu <at> gmail.com>.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact "Juanma Barranquero" <lekktu <at> gmail.com> by
replying to this email.


-- 
1433: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1433
Emacs Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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

[Message part 3 (message/rfc822, inline)]

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));
 }

Previous Next

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