bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Ken Brown]

Create a file "/tmp/Ü.txt".  (In case my mailer mangles this, that's 
<U-umlaut>.txt.)  Now open Windows Explorer and drag this file into an 
emacs frame.  This results in the error message

   dnd-open-local-file: Can not read file:///tmp/%20.txt

I think the problem occurs early in w32-handle-dropped-file (defined in 
lisp/term/w32-win.el).  That function starts with

(let ((f (if (eq system-type 'cygwin)
	     (cygwin-convert-file-name-from-windows file-name t)

At this point f should have the value "/tmp/Ü.txt".  If I continue 
manually carrying out the code in w32-handle-dropped-file as though f 
had that value, everything is fine, as shown below.  So 
cygwin-convert-file-name-from-windows must be doing something wrong.

Here's a session in the *scratch* buffer, imitating what 
w32-handle-dropped-file would do starting from the correct value of f:

(setq f "/tmp/Ü.txt")
"/tmp/Ü.txt"

(setq coding (or file-name-coding-system
		 default-file-name-coding-system))
utf-8-unix

(setq file-name
       (mapconcat 'url-hexify-string
		 (split-string (encode-coding-string f coding)
			       "/")
		 "/"))
"/tmp/%C3%9C.txt"

(setq uri (concat
	   (if (eq system-type 'cygwin)
	       "file://"
	     "file:")
	   file-name))
"file:///tmp/%C3%9C.txt"

(dnd-get-local-file-name uri t)
"/tmp/Ü.txt"


In GNU Emacs 24.3.50.4 (i686-pc-cygwin)
  of 2013-03-06 on fiona
Bzr revision: 111954 dmantipov@yandex.ru-20130306112630-ooq2zc4oq664z5zc
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
  `configure --with-w32 CFLAGS=-g3 -O0'

Important settings:
   value of $LANG: en_US.UTF-8
   locale-coding-system: utf-8-unix
   default enable-multibyte-characters: t

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Eli Zaretskii]

> Date: Fri, 08 Mar 2013 12:18:05 -0500
> From: Ken Brown <kbrown@cornell.edu>
> 
> Create a file "/tmp/Ü.txt".  (In case my mailer mangles this, that's 
> <U-umlaut>.txt.)  Now open Windows Explorer and drag this file into an 
> emacs frame.  This results in the error message
> 
>    dnd-open-local-file: Can not read file:///tmp/%20.txt
> 
> I think the problem occurs early in w32-handle-dropped-file (defined in 
> lisp/term/w32-win.el).  That function starts with
> 
> (let ((f (if (eq system-type 'cygwin)
> 	     (cygwin-convert-file-name-from-windows file-name t)
> 
> At this point f should have the value "/tmp/Ü.txt".  If I continue 
> manually carrying out the code in w32-handle-dropped-file as though f 
> had that value, everything is fine, as shown below.  So 
> cygwin-convert-file-name-from-windows must be doing something wrong.

What do you get from cygwin-convert-file-name-from-windows with this
file name?

Also, what is the system codepage on this system?

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Eli Zaretskii]

> Date: Fri, 08 Mar 2013 21:42:56 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 13907@debbugs.gnu.org
> 
> > Date: Fri, 08 Mar 2013 12:18:05 -0500
> > From: Ken Brown <kbrown@cornell.edu>
> > 
> > Create a file "/tmp/Ü.txt".  (In case my mailer mangles this, that's 
> > <U-umlaut>.txt.)  Now open Windows Explorer and drag this file into an 
> > emacs frame.  This results in the error message
> > 
> >    dnd-open-local-file: Can not read file:///tmp/%20.txt
> > 
> > I think the problem occurs early in w32-handle-dropped-file (defined in 
> > lisp/term/w32-win.el).  That function starts with
> > 
> > (let ((f (if (eq system-type 'cygwin)
> > 	     (cygwin-convert-file-name-from-windows file-name t)
> > 
> > At this point f should have the value "/tmp/Ü.txt".  If I continue 
> > manually carrying out the code in w32-handle-dropped-file as though f 
> > had that value, everything is fine, as shown below.  So 
> > cygwin-convert-file-name-from-windows must be doing something wrong.
> 
> What do you get from cygwin-convert-file-name-from-windows with this
> file name?
> 
> Also, what is the system codepage on this system?

In addition, please describe how you created the "/tmp/Ü.txt" file --
what command did you use?

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Eli Zaretskii]

> Date: Fri, 08 Mar 2013 21:42:56 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 13907@debbugs.gnu.org
> 
> > Date: Fri, 08 Mar 2013 12:18:05 -0500
> > From: Ken Brown <kbrown@cornell.edu>
> > 
> > Create a file "/tmp/Ü.txt".  (In case my mailer mangles this, that's 
> > <U-umlaut>.txt.)  Now open Windows Explorer and drag this file into an 
> > emacs frame.  This results in the error message
> > 
> >    dnd-open-local-file: Can not read file:///tmp/%20.txt
> > 
> > I think the problem occurs early in w32-handle-dropped-file (defined in 
> > lisp/term/w32-win.el).  That function starts with
> > 
> > (let ((f (if (eq system-type 'cygwin)
> > 	     (cygwin-convert-file-name-from-windows file-name t)
> > 
> > At this point f should have the value "/tmp/Ü.txt".  If I continue 
> > manually carrying out the code in w32-handle-dropped-file as though f 
> > had that value, everything is fine, as shown below.  So 
> > cygwin-convert-file-name-from-windows must be doing something wrong.
> 
> What do you get from cygwin-convert-file-name-from-windows with this
> file name?
> 
> Also, what is the system codepage on this system?

And one more question: what is the value of file-name _before_ it is
passed to cygwin-convert-file-name-from-windows?  Does it perhaps
already have the U-umlaut replaced by a blank?

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Eli Zaretskii]

> Date: Fri, 08 Mar 2013 22:33:07 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 13907@debbugs.gnu.org
> 
> And one more question: what is the value of file-name _before_ it is
> passed to cygwin-convert-file-name-from-windows?  Does it perhaps
> already have the U-umlaut replaced by a blank?

I think the problem is on the C level, not on the Lisp level.  Take a
look at w32term.c:construct_drag_n_drop -- it uses ANSI version of
DragQueryFile to get the file name, then decodes it by DECODE_FILE.
But DECODE_FILE uses UTF-8 in the cygw32 build, so this is
inappropriate for decoding file names that come from Windows APIs.

Instead, in the cygw32 build, construct_drag_n_drop should use
DragQueryFileW and convert the file name to the internal Emacs
representation using from_unicode.

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Ken Brown]

On 3/8/2013 3:53 PM, Eli Zaretskii wrote:
>> Date: Fri, 08 Mar 2013 22:33:07 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 13907@debbugs.gnu.org
>>
>> And one more question: what is the value of file-name _before_ it is
>> passed to cygwin-convert-file-name-from-windows?  Does it perhaps
>> already have the U-umlaut replaced by a blank?
>
> I think the problem is on the C level, not on the Lisp level.  Take a
> look at w32term.c:construct_drag_n_drop -- it uses ANSI version of
> DragQueryFile to get the file name, then decodes it by DECODE_FILE.
> But DECODE_FILE uses UTF-8 in the cygw32 build, so this is
> inappropriate for decoding file names that come from Windows APIs.
>
> Instead, in the cygw32 build, construct_drag_n_drop should use
> DragQueryFileW and convert the file name to the internal Emacs
> representation using from_unicode.

Thanks!  You solved it while I was trying to get the answers to your 
questions.  For the record, here's what happens in my example:

The value of file-name that is passed to 
cygwin-convert-file-name-from-windows is "C:\\cygwin\\tmp\\\334.txt". 
The converted file name is then "/tmp/ .txt".

I'll leave it to Daniel to fix this, since it's his code.

Thanks again, Eli.

Ken

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Eli Zaretskii]

> Date: Fri, 08 Mar 2013 16:03:25 -0500
> From: Ken Brown <kbrown@cornell.edu>
> CC: Daniel Colascione <dancol@dancol.org>, 13907@debbugs.gnu.org
> 
> The value of file-name that is passed to 
> cygwin-convert-file-name-from-windows is "C:\\cygwin\\tmp\\\334.txt". 
> The converted file name is then "/tmp/ .txt".

The appearance of a blank (or a question mark) instead of a character
is usually a tell-tale sign of a botched character conversion.

For example, when I drag-n-drop into a native w32 Emacs a file name
that includes characters not from the system codepage, I get this:

  dnd-open-local-file: Can not read file:D%3A/gnu/ispell-3.3.02.w32/dictionaries/Tatar-Rus-%3Fngliz%20s%3Fzlege.htm

(%3F is the question mark.)

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Daniel Colascione]

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

On 3/8/2013 12:53 PM, Eli Zaretskii wrote:
>> Date: Fri, 08 Mar 2013 22:33:07 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 13907@debbugs.gnu.org
>>
>> And one more question: what is the value of file-name _before_ it is
>> passed to cygwin-convert-file-name-from-windows?  Does it perhaps
>> already have the U-umlaut replaced by a blank?
> 
> I think the problem is on the C level, not on the Lisp level.  Take a
> look at w32term.c:construct_drag_n_drop -- it uses ANSI version of
> DragQueryFile to get the file name, then decodes it by DECODE_FILE.
> But DECODE_FILE uses UTF-8 in the cygw32 build, so this is
> inappropriate for decoding file names that come from Windows APIs.
> 
> Instead, in the cygw32 build, construct_drag_n_drop should use
> DragQueryFileW and convert the file name to the internal Emacs
> representation using from_unicode.
> 


Thanks for finding that! I've been swamped this week, and I haven't been able to
do any investigation. I'll see whether I can come up with a fix this weekend.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Daniel Colascione]

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

On 3/8/2013 1:25 PM, Daniel Colascione wrote:
> On 3/8/2013 12:53 PM, Eli Zaretskii wrote:
>>> Date: Fri, 08 Mar 2013 22:33:07 +0200
>>> From: Eli Zaretskii <eliz@gnu.org>
>>> Cc: 13907@debbugs.gnu.org
>>>
>>> And one more question: what is the value of file-name _before_ it is
>>> passed to cygwin-convert-file-name-from-windows?  Does it perhaps
>>> already have the U-umlaut replaced by a blank?
>>
>> I think the problem is on the C level, not on the Lisp level.  Take a
>> look at w32term.c:construct_drag_n_drop -- it uses ANSI version of
>> DragQueryFile to get the file name, then decodes it by DECODE_FILE.
>> But DECODE_FILE uses UTF-8 in the cygw32 build, so this is
>> inappropriate for decoding file names that come from Windows APIs.
>>
>> Instead, in the cygw32 build, construct_drag_n_drop should use
>> DragQueryFileW and convert the file name to the internal Emacs
>> representation using from_unicode.
>>
> 
> 
> Thanks for finding that! I've been swamped this week, and I haven't been able to
> do any investigation. I'll see whether I can come up with a fix this weekend.
> 

The patch below resolves the issue for me. Assuming it's acceptable, where
should I install it?

~/edev/trunk
$ bzr diff
=== modified file 'src/w32term.c'
--- src/w32term.c       2013-02-16 13:59:37 +0000
+++ src/w32term.c       2013-03-09 03:02:10 +0000
@@ -3186,12 +3186,27 @@

   for (i = 0; i < num_files; i++)
     {
+#ifdef NTGUI_UNICODE
+      len = DragQueryFileW (hdrop, i, NULL, 0);
+      if (len <= 0)
+       continue;
+
+      name = alloca ((len + 1) * sizeof (wchar_t));
+      DragQueryFileW (hdrop, i, (wchar_t *) name, len + 1);
+      files = Fcons (
+        from_unicode (make_unibyte_string(
+                        name,
+                        1 + sizeof (wchar_t) * len)),
+        files);
+#else
       len = DragQueryFile (hdrop, i, NULL, 0);
       if (len <= 0)
        continue;
+
       name = alloca (len + 1);
       DragQueryFile (hdrop, i, name, len + 1);
       files = Fcons (DECODE_FILE (build_string (name)), files);
+#endif /* NTGUI_UNICODE */
     }

   DragFinish (hdrop);




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Daniel Colascione]

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

On 3/8/2013 7:03 PM, Daniel Colascione wrote:
> On 3/8/2013 1:25 PM, Daniel Colascione wrote:
>> On 3/8/2013 12:53 PM, Eli Zaretskii wrote:
>>>> Date: Fri, 08 Mar 2013 22:33:07 +0200
>>>> From: Eli Zaretskii <eliz@gnu.org>
>>>> Cc: 13907@debbugs.gnu.org
>>>>
>>>> And one more question: what is the value of file-name _before_ it is
>>>> passed to cygwin-convert-file-name-from-windows?  Does it perhaps
>>>> already have the U-umlaut replaced by a blank?
>>>
>>> I think the problem is on the C level, not on the Lisp level.  Take a
>>> look at w32term.c:construct_drag_n_drop -- it uses ANSI version of
>>> DragQueryFile to get the file name, then decodes it by DECODE_FILE.
>>> But DECODE_FILE uses UTF-8 in the cygw32 build, so this is
>>> inappropriate for decoding file names that come from Windows APIs.
>>>
>>> Instead, in the cygw32 build, construct_drag_n_drop should use
>>> DragQueryFileW and convert the file name to the internal Emacs
>>> representation using from_unicode.
>>>
>>
>>
>> Thanks for finding that! I've been swamped this week, and I haven't been able to
>> do any investigation. I'll see whether I can come up with a fix this weekend.
>>
> 
> The patch below resolves the issue for me. Assuming it's acceptable, where
> should I install it?
> 
> ~/edev/trunk
> $ bzr diff
> === modified file 'src/w32term.c'
> --- src/w32term.c       2013-02-16 13:59:37 +0000
> +++ src/w32term.c       2013-03-09 03:02:10 +0000
> @@ -3186,12 +3186,27 @@
> 
>    for (i = 0; i < num_files; i++)
>      {
> +#ifdef NTGUI_UNICODE
> +      len = DragQueryFileW (hdrop, i, NULL, 0);
> +      if (len <= 0)
> +       continue;
> +
> +      name = alloca ((len + 1) * sizeof (wchar_t));
> +      DragQueryFileW (hdrop, i, (wchar_t *) name, len + 1);
> +      files = Fcons (
> +        from_unicode (make_unibyte_string(
> +                        name,
> +                        1 + sizeof (wchar_t) * len)),
> +        files);
> +#else
>        len = DragQueryFile (hdrop, i, NULL, 0);
>        if (len <= 0)
>         continue;
> +
>        name = alloca (len + 1);
>        DragQueryFile (hdrop, i, name, len + 1);
>        files = Fcons (DECODE_FILE (build_string (name)), files);
> +#endif /* NTGUI_UNICODE */
>      }
> 
>    DragFinish (hdrop);

By the way: shouldn't we have an unwind handler here so that we call DragFinish
even if our memory allocation fails?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Eli Zaretskii]

> Date: Fri, 08 Mar 2013 19:03:58 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: 13907@debbugs.gnu.org
> 
> By the way: shouldn't we have an unwind handler here so that we call DragFinish
> even if our memory allocation fails?

What memory allocation?  If you mean 'alloca', its failure is
generally a fatal exception, which means we are no longer in a
position to call anything ;-)

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Daniel Colascione]

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

On 3/9/13 12:32 AM, Eli Zaretskii wrote:
>> Date: Fri, 08 Mar 2013 19:03:58 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: 13907@debbugs.gnu.org
>>
>> By the way: shouldn't we have an unwind handler here so that we call DragFinish
>> even if our memory allocation fails?
> 
> What memory allocation?  If you mean 'alloca', its failure is
> generally a fatal exception, which means we are no longer in a
> position to call anything ;-)
> 

We're consing, aren't we? If we can't cons, even after gc, we
longjmp out in memory_full, right? Granted, I haven't seen that
happen in years.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Eli Zaretskii]

> Date: Sat, 09 Mar 2013 00:37:40 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: 13907@debbugs.gnu.org
> 
> On 3/9/13 12:32 AM, Eli Zaretskii wrote:
> >> Date: Fri, 08 Mar 2013 19:03:58 -0800
> >> From: Daniel Colascione <dancol@dancol.org>
> >> CC: 13907@debbugs.gnu.org
> >>
> >> By the way: shouldn't we have an unwind handler here so that we call DragFinish
> >> even if our memory allocation fails?
> > 
> > What memory allocation?  If you mean 'alloca', its failure is
> > generally a fatal exception, which means we are no longer in a
> > position to call anything ;-)
> > 
> 
> We're consing, aren't we? If we can't cons, even after gc, we
> longjmp out in memory_full, right?

Right.

Well, DragFinish just releases memory, so it's not terribly important
to make sure we call it if we end up in memory_full.  But it might be
good for cleaner code, yes.

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Daniel Colascione]

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

On 3/9/13 12:32 AM, Eli Zaretskii wrote:
>> Date: Fri, 08 Mar 2013 19:03:58 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: 13907@debbugs.gnu.org
>>
>> By the way: shouldn't we have an unwind handler here so that we call DragFinish
>> even if our memory allocation fails?
> 
> What memory allocation?  If you mean 'alloca', its failure is
> generally a fatal exception, which means we are no longer in a
> position to call anything ;-)
> 

We're consing, aren't we? If we can't cons, even after gc, we
longjmp out in memory_full, right? Granted, I haven't seen that
happen in years.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Daniel Colascione]

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

On 3/8/2013 7:03 PM, Daniel Colascione wrote:
> On 3/8/2013 7:03 PM, Daniel Colascione wrote:
>> On 3/8/2013 1:25 PM, Daniel Colascione wrote:
>>> On 3/8/2013 12:53 PM, Eli Zaretskii wrote:
>>>>> Date: Fri, 08 Mar 2013 22:33:07 +0200
>>>>> From: Eli Zaretskii <eliz@gnu.org>
>>>>> Cc: 13907@debbugs.gnu.org
>>>>>
>>>>> And one more question: what is the value of file-name _before_ it is
>>>>> passed to cygwin-convert-file-name-from-windows?  Does it perhaps
>>>>> already have the U-umlaut replaced by a blank?
>>>>
>>>> I think the problem is on the C level, not on the Lisp level.  Take a
>>>> look at w32term.c:construct_drag_n_drop -- it uses ANSI version of
>>>> DragQueryFile to get the file name, then decodes it by DECODE_FILE.
>>>> But DECODE_FILE uses UTF-8 in the cygw32 build, so this is
>>>> inappropriate for decoding file names that come from Windows APIs.
>>>>
>>>> Instead, in the cygw32 build, construct_drag_n_drop should use
>>>> DragQueryFileW and convert the file name to the internal Emacs
>>>> representation using from_unicode.
>>>>
>>>
>>>
>>> Thanks for finding that! I've been swamped this week, and I haven't been able to
>>> do any investigation. I'll see whether I can come up with a fix this weekend.
>>>
>>
>> The patch below resolves the issue for me. Assuming it's acceptable, where
>> should I install it?

bzr trunk revision 111999 resolves this bug, the title-bar bug, and a few others
relating to mismatches between the Windows GUI encoding and the Cygwin system
encoding. Ken, it's probably this change that you want to backport to your
Cygwin package.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Ken Brown]

On 3/10/2013 7:00 PM, Daniel Colascione wrote:
> bzr trunk revision 111999 resolves this bug, the title-bar bug, and a few others
> relating to mismatches between the Windows GUI encoding and the Cygwin system
> encoding. Ken, it's probably this change that you want to backport to your
> Cygwin package.

Thanks, Daniel!  I'm closing the bug.

Ken

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Ken Brown]

On 3/8/2013 10:03 PM, Daniel Colascione wrote:
> On 3/8/2013 1:25 PM, Daniel Colascione wrote:
>> On 3/8/2013 12:53 PM, Eli Zaretskii wrote:
>>>> Date: Fri, 08 Mar 2013 22:33:07 +0200
>>>> From: Eli Zaretskii <eliz@gnu.org>
>>>> Cc: 13907@debbugs.gnu.org
>>>>
>>>> And one more question: what is the value of file-name _before_ it is
>>>> passed to cygwin-convert-file-name-from-windows?  Does it perhaps
>>>> already have the U-umlaut replaced by a blank?
>>>
>>> I think the problem is on the C level, not on the Lisp level.  Take a
>>> look at w32term.c:construct_drag_n_drop -- it uses ANSI version of
>>> DragQueryFile to get the file name, then decodes it by DECODE_FILE.
>>> But DECODE_FILE uses UTF-8 in the cygw32 build, so this is
>>> inappropriate for decoding file names that come from Windows APIs.
>>>
>>> Instead, in the cygw32 build, construct_drag_n_drop should use
>>> DragQueryFileW and convert the file name to the internal Emacs
>>> representation using from_unicode.
>>>
>>
>>
>> Thanks for finding that! I've been swamped this week, and I haven't been able to
>> do any investigation. I'll see whether I can come up with a fix this weekend.
>>
>
> The patch below resolves the issue for me. Assuming it's acceptable, where
> should I install it?

It fixes it for me too.  Thanks.

Ken

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name

[Glenn Morris]

Daniel Colascione wrote:

> The patch below resolves the issue for me. Assuming it's acceptable, where
> should I install it?

To trunk, IMO.