On 05/06/2008 05:16 PM, [EMAIL PROTECTED] wrote:
Author: wrowe
Date: Tue May 6 08:16:58 2008
New Revision: 653805
URL: http://svn.apache.org/viewvc?rev=653805&view=rev
Log:
Reduce the point at which we use long filename manipulation to 248
characters, as "path names" are further constrained to 248 rather
than MAX_PATH chars.
Submitted by: Stefan <steveking gmx.ch>
Modified:
apr/apr/trunk/file_io/win32/open.c
Modified: apr/apr/trunk/file_io/win32/open.c
URL:
http://svn.apache.org/viewvc/apr/apr/trunk/file_io/win32/open.c?rev=653805&r1=653804&r2=653805&view=diff
==============================================================================
--- apr/apr/trunk/file_io/win32/open.c (original)
+++ apr/apr/trunk/file_io/win32/open.c Tue May 6 08:16:58 2008
@@ -55,17 +55,20 @@
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 characters. 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]
* or call the Win32 API functions such as GetModuleName, etc.
* Not every application is prepared to handle such names.
+ *
+ * Note also this is shorter than MAX_PATH, as directory paths
+ * are actually limited to 248 characters.
*
* 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) {
Shouldn't 248 be a #define? I am normally uneasy with using such numbers
directly
in the code.
Regards
Rüdiger
