Hi,
While debugging problems with Subversion on Windows (checkouts failed if
some paths had longer names than around 250 chars), I found a bug in apr:
apr transparently converts long pathnames to the Windows specific format
for long names (it prepends '\\?\'). But that only works properly for
files, because only filenames can be up to MAX_PATH chars long before
the other format is needed. Directories can only be 248 chars long
before the long format is required (see MSDN docs for CreateDirectory:
http://msdn2.microsoft.com/en-us/library/aa363855(VS.85).aspx).
Since the function utf8_to_unicode_path() does the converting for both
file and dir paths, it has to use the long format for 248 length strings
on, not MAX_PATH. Otherwise, directory creation fails (at least for
paths between 248 chars and 260 chars in length).
The attached patch fixes this problem.
Stefan
Index: file_io/win32/open.c
===================================================================
--- file_io/win32/open.c (revision 613400)
+++ file_io/win32/open.c (working copy)
@@ -55,7 +55,7 @@
apr_status_t rv;
/* This is correct, we don't twist the filename if it is will
- * definately be shorter than MAX_PATH. It merits some
+ * definately be shorter than 248. 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[0]
@@ -65,7 +65,7 @@
* Note that a utf-8 name can never result in more wide chars
* than the original number of utf-8 narrow chars.
*/
- if (srcremains > MAX_PATH) {
+ if (srcremains > 248) {
if (srcstr[1] == ':' && (srcstr[2] == '/' || srcstr[2] == '\\')) {
wcscpy (retstr, L"\\\\?\\");
retlen -= 4;
