[PATCH] PR21482: long paths on Windows

Robinson, Paul Paul_Robinson at playstation.sony.com
Tue Nov 11 07:27:50 PST 2014


New patch attached.

I ended up not using make_absolute because it caused more string copying.
If there's some reason to consider it safer than current_path and doing
my own pasting, I can do that instead, but only if y'all think it has
actual value.

This changed the specific error returned by another fs test, which
seems reasonable.
--paulr

> -----Original Message-----
> From: Michael Spencer [mailto:bigcheesegs at gmail.com]
> Sent: Monday, November 10, 2014 4:04 PM
> To: Robinson, Paul
> Cc: Aaron Ballman; Rafael Espíndola; llvm-commits at cs.uiuc.edu
> Subject: Re: [PATCH] PR21482: long paths on Windows
> 
> On Mon, Nov 10, 2014 at 3:05 PM, Robinson, Paul
> <Paul_Robinson at playstation.sony.com> wrote:
> >> -----Original Message-----
> >> From: Aaron Ballman [mailto:aaron.ballman at gmail.com]
> >> Sent: Monday, November 10, 2014 2:47 PM
> >> To: Rafael Espíndola
> >> Cc: Robinson, Paul; llvm-commits at cs.uiuc.edu
> >> Subject: Re: [PATCH] PR21482: long paths on Windows
> >>
> >> On Mon, Nov 10, 2014 at 5:43 PM, Rafael Espíndola
> >> <rafael.espindola at gmail.com> wrote:
> >> > static std::error_code widen_path(const Twine &Path8,
> >> >
> >> > widenPath
> >> >
> >> > Using  '\\?\'  also disables using / as a path separator, no? Don't
> we
> >> > have to check/assert that there is no / in Path8?
> >
> > So for paranoia I should translate all / to \ in the widened path?  I
> don't
> > see any existing utility to do that, but easy enough to invent one.
> 
> sys::path::native(). in Path.h
> 
> We also have make_absolute in FileSystem.h
> 
> - Michael Spencer
> 
> >
> >> >
> >> > +  size_t NLevels = ((248 - TmpLen) / 10) + 1;
> >> > +  const char *OneDir = "\\123456789";
> >> >
> >> > Use the size of OneDir instead of hard codding the 10.
> >> >
> >> > Aaron, this only uses '\\?\' to create long paths. They can still be
> >> > accessed by regular tools by changing the current directory, no?
> >>
> >> Yes, relative paths aren't an issue. Just tools using absolute paths
> >> that don't support the extended path namespace (which can happen if
> >> the app assumes MAX_PATH is actually the max).
> >>
> >> ~Aaron
> >>
> >> >
> >> > On 10 November 2014 16:01, 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.
> >> >> --paulr
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> llvm-commits mailing list
> >> >> llvm-commits at cs.uiuc.edu
> >> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >> >>
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
-------------- next part --------------
A non-text attachment was scrubbed...
Name: path-abs3.patch
Type: application/octet-stream
Size: 8893 bytes
Desc: path-abs3.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141111/ae4eb7cb/attachment.obj>


More information about the llvm-commits mailing list