Add Windows long path support #110
Conversation
This adds support for Windows long paths through the "\\?\" namespace. Note that some internal Windows APIs don't support longer paths (_wmktemp, _wchdir), and shells don't like the "\\?\" namespace, so the internal length may still be limited. Thanks-to: nitram509 <maki@bitkings.de> Signed-off-by: Doug Kelly <dougk.ff7@gmail.com>
|
@dscho Here's my take on integrating the work @nitram509 did previously. I based some of this on my own experiences trying this, too. It did appear to pass through the entire regression test suite (when compared with unmodified code), so I believe it's working correctly, but as noted in the code, there are some caveats for functions that don't support the long path syntax. Additionally, I believe @kblees pointed out that the code as-is may not support UNC paths. I'm not sure how vital that is, and I didn't attempt to address it either. |
|
MSysGit - the development behind Git for Windows » git #157 SUCCESS |
| @@ -480,7 +480,8 @@ int mingw_chdir(const char *dirname) | |||
| wchar_t wdirname[MAX_PATH]; | |||
| if (xutftowcs_canonical_path(wdirname, dirname) < 0) | |||
| return -1; | |||
| return _wchdir(wdirname); | |||
| /* TODO: _wchdir() does not support long paths */ | |||
There was a problem hiding this comment.
Where did you find that information? This page suggests to me that all Unicode functions in the Win32 API can handle long names, and creating directories is mentioned specifically (including the note that the limit for directory names is actually SHRT_MAX - 12 to allow for an 8.3 file name to be appended... (I failed to see any note about length limitations on _wmkdir's documentation on MSDN either...)
There was a problem hiding this comment.
Good question. And I wish I could find the documentation on it again. Unfortunately, even if there is no documentation, it doesn't change the fact it won't work. :) Without stripping "\?", you'll find that a number of these functions simply don't work -- you get erratic behavior, and it's clear these functions are to blame. Here's some reading on why "\?" is so ... frustrating sometimes:
http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2003/12/10/56028.aspx (hey, CreateProcess can have long paths... but apparently will balk if you send it "\?")
http://stackoverflow.com/questions/1880321/why-does-the-260-character-path-length-limit-exist-in-windows
http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2156195-fix-260-character-file-name-length-limitation (Basically, Visual Studio team has declined to investigate this issue)
There was a problem hiding this comment.
That's too bad! However, I find those links so informative that I would strongly suggest putting them into the commit message (remember, commit messages are the perfect place to put information related to the change that cannot be directly inferred from the diff).
There was a problem hiding this comment.
Could it be that we need to call SetCurrentDirectoryW instead of _wchdir?
There was a problem hiding this comment.
Good question! Unfortunately, it seems _wchdir() calls SetCurrentDirectoryW and that does, in fact, have a hard limit of 260 characters. http://msdn.microsoft.com/en-us/library/windows/desktop/aa365530(v=vs.85).aspx
There was a problem hiding this comment.
That's too bad. However, let's just do as good as we can (not better)... I am willing to stay with _wchdir()...
|
Closed in favor of #122. |
This adds support for Windows long paths through the "?"
namespace. Note that some internal Windows APIs don't support
longer paths (_wmktemp, _wchdir), and shells don't like the "?"
namespace, so the internal length may still be limited.
Thanks-to: nitram509 maki@bitkings.de
Signed-off-by: Doug Kelly dougk.ff7@gmail.com