Re: [Emacs-diffs] master 7466a4d: Cygwin emacsclient handles w32 file names

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 01 Jul 2015 10:14:20 -0400
> From: Ken Brown <kbrown@cornell.edu>
> Cc: emacs-devel@gnu.org
> 
> I've tested this a little with file names containing UTF-8-encoded 
> Chinese and other non-ASCII characters, and it appears to work OK.  But 
> I *think* it only works because of accidental implementation details of 
> cygwin-convert-file-name-from-windows (and the underlying Cygwin 
> function cygwin_conv_path).  Basically, it seems that these functions 
> don't actually try to do any conversion if they are given a multibyte 
> string instead of the expected UTF-16 string.

That was also my conclusion.

> So even though this change *might* be harmless, I think it could lead to 
> bugs later if implementations change.  I don't think 
> cygwin-convert-file-name-from-windows should be called on a file name 
> that is not known to be a (UTF-16-encoded) Windows file name.

The UTF-16 encoding is not an issue, because
cygwin-convert-file-name-from-windows calls to_unicode to ensure that.

I think this code needs to look at the result of expand-file-name for
the file and the default directory in effect, and check whether the
result begins with a drive letter.  If it does, it should call
cygwin-convert-file-name-from-windows.