[PATCH] PR21482: long paths on Windows

Michael Spencer bigcheesegs at gmail.com
Tue Nov 11 12:35:50 PST 2014


On Tue, Nov 11, 2014 at 7:27 AM, Robinson, Paul
<Paul_Robinson at playstation.sony.com> wrote:
> 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

This patch doesn't seem to be able to handle "..\foo". \\?\ disables
expansion of . and ..

Other than that it looks fine.

- Michael Spencer

>
>> -----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




More information about the llvm-commits mailing list