bug#13553: 24.3.50; incorrect usage of IS_DIRECTORY_SEP

[Shigeru Fukaya <shigeru.fukaya@gmail.com>]

I greatly appreciate your very quick work, thank you.

I looked through your fix of all functions
(parse_root, get_volume_info, readdir, read_unc_volume, 
logon_network_drive, star_worker, symlink, chase_symlinks)
one by one, and found good at first look.

I'll try build and check it next, anyway.

Yes, my `w32-get-true-file-attributes' is nil. (Isn't it default?)

As for coding symbol, not a few Japanese use 'cp932 not 'shift-jis I 
suppose.  But we need some notice for users.

Regards,
Shigeru


>> From: Shigeru Fukaya <shigeru.fukaya@gmail.com>
>> Date: Sat, 26 Jan 2013 14:52:59 +0900
>> 
>> `file-attributes' returns nil as stat info for a file, its name ending
>> with a character whose second byte is 0x5c.
>> 
>> It is because IS_DIRECTORY_SEP is wrongly used.
>> IS_DIRECTORY_SEP only works when its argument is surely on a start
>> byte of dbcs characters.
>> I find incorrect usage, at least in some functions of `w32.c'.
>> (readdir, stat_worker, read_unc_volume)
>
>Thanks.  I fixed w32.c functions that use IS_DIRECTORY_SEP in revision
>111200 on the emacs-24 branch.  As I cannot easily test DBCS file-name
>encodings on my system, please test the fixed version and see if the
>problem indeed goes away.  The patch relative to emacs-24 branch is
>below, for your convenience.
>
>After looking at the code which I fixed, I'm afraid I don't understand
>why file-attributes returned nil in your case.  The code that uses
>IS_DIRECTORY_SEP there is only a fallback, for when the
>GetFileInformationByHandle API fails for some reason.  You don't say
>what version of Windows you are using, but I won't expect that
>fallback code be executed for any reasonably recent Windows version.
>
>So could you please trace through the code that file-attributes calls,
>and see which use of IS_DIRECTORY_SEP caused the problem?  I'm afraid
>that it's not in w32.c at all, but elsewhere.
>
>
>=== modified file 'src/w32.c'
...