Re: [patch] creating directories with long names
Erik Huelsmann wrote: On Tue, Feb 5, 2008 at 8:57 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Stefan Küng wrote: Anyone looked at this yet? http://mail-archives.apache.org/mod_mbox/apr-dev/200801.mbox/[EMAIL PROTECTED] The patch/argument made perfect sense, although I'm leaning towards a switch to decide if it's a file or path name (if it is even possible for that to work). I'll review and commit. We're seeing this problem more and more often popping up on [EMAIL PROTECTED] Any progress on the issue? Committed for 1.3 and 0.9, thanks for the reminders guys! Bill
Re: [patch] creating directories with long names
On Tue, Feb 5, 2008 at 8:57 PM, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Stefan Küng wrote: Anyone looked at this yet? http://mail-archives.apache.org/mod_mbox/apr-dev/200801.mbox/[EMAIL PROTECTED] The patch/argument made perfect sense, although I'm leaning towards a switch to decide if it's a file or path name (if it is even possible for that to work). I'll review and commit. We're seeing this problem more and more often popping up on [EMAIL PROTECTED] Any progress on the issue? Thanks in advance. Bye, Erik.
Re: [patch] creating directories with long names
Anyone looked at this yet?
http://mail-archives.apache.org/mod_mbox/apr-dev/200801.mbox/[EMAIL PROTECTED]
Stefan
Stefan Küng wrote:
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;
--
___
oo // \\ De Chelonian Mobile
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
signature.asc
Description: OpenPGP digital signature
Re: [patch] creating directories with long names
Stefan Küng wrote: Anyone looked at this yet? http://mail-archives.apache.org/mod_mbox/apr-dev/200801.mbox/[EMAIL PROTECTED] The patch/argument made perfect sense, although I'm leaning towards a switch to decide if it's a file or path name (if it is even possible for that to work). I'll review and commit.
[patch] creating directories with long names
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;
