Branko ─îibej wrote:
> a) Only work on Win NT and later (not Win9x) -- not that I care about
> those platforms, and
> b) APR already does that with file names on Windows, so it doesn't
> always seem to help.
Maybe I'm missing something. However, looking at utf8_to_unicode_path,
I see that this only happens if (srcremains > MAX_PATH); with the
/* This is correct, we don't twist the filename if it is will
* definately be shorter than MAX_PATH. It merits some
* performance testing to see if this has any effect, but there
* seem to be applications that get confused by the resulting
* Unicode \\?\ style file names, especially if they use argv
* or call the Win32 API functions such as GetModuleName, etc.
* Not every application is prepared to handle such names.
* Note that a utf-8 name can never result in more wide chars
* than the original number of utf-8 narrow chars.
So APR doesn't do this always; I my case, the path much shorter
> Anyway, this isn't the only kind of file name that won't work on
> Windows; file names with colons or backslashes in them (which can be
> created on Unix) will also break the Windows client.
Right. I wonder how subversion behaves when confronted with such
a file. Will it create an addition data stream?
Interix uses some mapping algorithm to support such file names,
mapping them into the Private Use Area of Unicode.
> Our position in similar situations in the past is that it's not
> Subversion's job to support file names that the native OS can't handle.
Ok, may I then file a bug that Subversion should stop claiming that
there were local modifications, when there weren't any?
> We know that, but we also know that it would be a pretty pointless thing
> to do, because other apps couldn't use such files.
That's not true. Interix apps can use them with no problems, and
Win32 apps typically can use them when passed the fully-escaped file
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Jan 21 00:56:46 2006