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;

Reply via email to