bug#1433: marked as done (filename coding systems and w32-*-file-name functions)

bug#1433: marked as done (filename coding systems and w32-*-file-name functions)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]


Your message dated Sat, 29 Nov 2008 19:40:18 +0100
with message-id <f7ccd24b0811291040i62c4f5b3j5ca4e9e7b6cbc437@mail.gmail.com>
and subject line 
has caused the Emacs bug report #1433,
regarding filename coding systems and w32-*-file-name functions
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
1433: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1433
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 7087 bytes --]

From: "Juanma Barranquero" <lekktu@gmail.com>
To: quiet@emacsbugs.donarmstrong.com
Subject: filename coding systems and w32-*-file-name functions
Date: Wed, 26 Nov 2008 15:38:00 +0100
Message-ID: <f7ccd24b0811260638p12b982a8o9ac7b93fe23f657@mail.gmail.com>

Package: emacs,w32
X-Debbugs-CC: jasonr@gnu.org


---------- Forwarded message ----------
From: Juanma Barranquero <lekktu@gmail.com>
Date: Tue, Nov 25, 2008 at 02:38
Subject: filename coding systems and w32-*-file-name functions
To: Emacs Devel <emacs-devel@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));
 }

[-- Attachment #3: Type: message/rfc822, Size: 2371 bytes --]

From: "Juanma Barranquero" <lekktu@gmail.com>
To: 1433-done@emacsbugs.donarmstrong.com
Subject: 
Date: Sat, 29 Nov 2008 19:40:18 +0100
Message-ID: <f7ccd24b0811291040i62c4f5b3j5ca4e9e7b6cbc437@mail.gmail.com>

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