Re: file-attribute on certain Chinese filenames failed

[Kenichi Handa <handa@m17n.org>]

In article <45c9d948.5c6acfa4.4c9b.ffffeb01@mx.google.com>, MJ Chan <mjchan.inbox@gmail.com> writes:

> I had trouble in accessing some files that contains certain Chinese
> (big5) characters (in fact, I found only one character so far that is
> causing the problem; all others are good). After checking around, I
> found that the problem would take place in "lstat" call in the C
> source. One example is in "file-attributes" (src/dired.c).

> For example, if I created a file named "=26345" (see below for the
> "describe-char" on that particular Chinese character) and then
> evaluated this, it returned nil. 

> (file-attributes "=26345")
> nil

I can't reproduce that problem on GNU/Linux.  For instance,
it seems that this code work correctly.

(let ((file-name-coding-system 'big5)
      (filename (string #x26345)))
  (with-temp-file filename (insert "abc\n"))
  (file-attributes filename))

=> (nil 1 8308 8308 (17873 19356) (17873 19356) (17873 19356)
    4 "-rw-rw-r--" nil 11175288 21)

But, when I run the same code on Windows, write-region
causes this error:

(file-error "Opening output file" "invalid argument"
            "c:/cygwin/home/handa/\x26345")

I suspect that this is because the big5 sequence of the
character #x26345 is "\267|", and Windows-XP (at least my
Japanese version) doesn't allow creating a file containing
"|".  For instance, I can't create a file "a|" either.

> As mentioned above, the culprit seems to be in calling lstat with
> encoded version of the file name as shown below (taken from dired.c)

>   GCPRO1 (filename);
>   encoded = ENCODE_FILE (filename);
>   UNGCPRO;

>   if (lstat (SDATA (encoded), &s) < 0)

>     return Qnil;

> If I changed the call to use un-encoded filename (i.e. lstat
> (filename,...)), then it is good. But I am not sure if this is the
> right thing to do. 

I believe it's not the right fix, and first of all, I have
no idea why such a change fixes your case.

Anyway, it seems that this is an Windows specific problem.

---
Kenichi Handa
handa@m17n.org