[p4] Windows file name length issues
qazwart at gmail.com
Sun Aug 19 17:59:17 PDT 2007
I take it that the answer is "no". Windows Vista is also stuck with
MAX_PATH, and as long as Perforce, Microsoft Office, and Windows
Explorer use the old non-Unicode Windows APIs, there is no way around
I also found this blog post:
which explains many of the issues with using long file names.
Apparently, using the new xxxxW APIs is not much of a solution because
(quoting directly from the blog:
> First about security, the \\?\ prefix not only enables long paths; it causes the path to > be passed to the file system with minimal modification by the Windows APIs. A
> consequence is that \\?\ turns off file name normalization performed by Windows
> APIs, including removing trailing spaces, expanding '.' and '..', converting relative
> paths into full paths, and so on.
Which may explain why even Microsoft's own program still use the old
APIs and hit the MAX_PATH limit.
RIght now, the best solution is to watch the length of your directory
names, and to keep Perforce clients and depots on the server close to
the root of the drive.
On 8/19/07, Patrick Bennett <patrick.bennett at inin.com> wrote:
> David Weintraub wrote:
> > Let me restate my question, if I am using Perforce on Windows Vista,
> > do I run into the same problems I would on Windows XP with the
> > MAX_PATH limitation?
> With Perforce itself? That is an issue with how Perforce calls the
> Win32 API's in the P4 API and various clients.
> If they're calling the A versions explicitly and relying on MBCS for
> Unicode support (yuck), it's a very simple matter for them to instead
> use the xxxW versions directly always passing (or converting to) UTF-16
> [which the W versions expect]. If they still want to support Win9x
> clients, then it's easy enough to abstract that way and only call the
> xxxW api's (which aren't in Win9x) by dynamically loading them upon
> detection of an NT-class OS.
> Patrick Bennett
qazwart at gmail.com
More information about the perforce-user