[PATCH] PR21482: long paths on Windows

[Robinson, Paul]

My understanding is that CMD.EXE is the one that can't handle them, while
Explorer actually can.  At least that's what happened to me while I was
testing this. :-)  But if that's a real concern, then perhaps the better
approach is to do better at failing when pathnames get too long?  I ran
into this because a path (not of my own devising) became too long and
Clang silently failed to do the right thing, for whatever definition of
"right thing" you care to choose.
--paulr

> -----Original Message-----
> From: aaron.ballman at gmail.com [mailto:aaron.ballman at gmail.com] On Behalf
> Of Aaron Ballman
> Sent: Monday, November 10, 2014 2:23 PM
> To: Robinson, Paul
> Cc: llvm-commits at cs.uiuc.edu
> Subject: Re: [PATCH] PR21482: long paths on Windows
> 
> On Mon, Nov 10, 2014 at 4:01 PM, Robinson, Paul
> <Paul_Robinson at playstation.sony.com> wrote:
> > Support directory names longer than 248 characters on Windows.
> >
> > The normal Windows path limit is 260 characters; the limit for directory
> > names is 248, to leave room for an 8.3 filename at the end.  Adding the
> > '\\?\' prefix greatly expands these limits.  Intercept path names that
> > we are about to pass to the Windows APIs and add the prefix if
> necessary.
> >
> > Also correct the comment about the state of the temporary directory used
> > by the Support unittests.
> 
> I don't have strong opinions on the patch, but would like to point out
> that we have to be very careful with the extended path namespace as it
> means we may create files that the user cannot access through "usual"
> means in Explorer. For instance, we can create files by accident that
> cannot be deleted by the user without some arcane efforts.
> 
> ~Aaron