Front page | perl.perl5.porters |
Postings from May 2017
Re: Long path names on Windows
Thread Previous
From:
Zakariyya Mughal
Date:
May 9, 2017 15:25
Subject:
Re: Long path names on Windows
Message ID:
20170509152512.pj5rbfrlwcmrcczp@msi-vm
On 2017-05-09 at 16:14:09 +0200, demerphq wrote:
> On 9 May 2017 at 10:16, Leon Timmermans <fawaka@gmail.com> wrote:
> > On Tue, May 9, 2017 at 9:40 AM, demerphq <demerphq@gmail.com> wrote:
> >>
> >> On 9 May 2017 09:36, "Leon Timmermans" <fawaka@gmail.com> wrote:
> >>
> >> On Tue, May 9, 2017 at 5:11 AM, Zakariyya Mughal <zaki.mughal@gmail.com>
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> Has there been any progress on supporting long path names on Windows? I
> >>> noticed that there have been changes in Windows 10 that let you opt-in
> >>> to bypassing the `MAX_PATH` limit by setting up a manifest and registry
> >>> key:
> >>>
> >>> - <https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath>
> >>> -
> >>> <https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/>
> >>>
> >>> (spotted on the Python bug tracker <https://bugs.python.org/issue18199>,
> >>> <https://bugs.python.org/issue27731>).
> >>>
> >>> However, it seems that these changes depend on using the wide-char
> >>> versions of the API functions. I see that there is already an issue for
> >>> this here <https://rt.perl.org/Public/Bug/Display.html?id=60888> (and
> >>> the associated meta issue for Unicode and system calls
> >>> <https://rt.perl.org/Public/Bug/Display.html?id=105914>).
> >>>
> >>> If this can not be done yet, it might be useful to catch the error when
> >>> calls like open() fail on Windows. Right now the output of accessing a
> >>> long file path on Windows looks like this:
> >>>
> >>> ```perl
> >>> use autodie;
> >>> open($long_path);
> >>> ```
> >>>
> >>> ```output
> >>> Can't open('$long_path'): No such file or directory
> >>> ```
> >>>
> >>> When I use built-in commands like `dir`, it tells me: `The filename or
> >>> extension is too long.` which is more informative.
> >>
> >>
> >> I agree this is highly desirable, but it is also rather difficult to
> >> achieve. It would involve both language design challenges and implementation
> >> challenges. I suspect this will require grant work given the size and scope
> >> of it.
> >>
> >>
> >> Leon, I can understand the need for implementation details but why does
> >> it need language changes?
> >>
> >> Yves
> >
> >
> > open and other built-ins taking paths are some of the last places that
> > suffer from The Unicode Bug. Fixing this would be a breaking change that
> > will need to be dealt with one way or another. It also means making a
> > distinction between platforms where paths are binary data (Unix) and
> > platforms where they are text (Windows).
>
> HRM. While i hear that you technically it might be a breaking change,
> in practice I think people on Windows take care to avoid unicode
> filenames, and probably would not object if they started working....
>
> Yves
I think there may be a quick way to see the effects of making this
change.
We can compare Windows Perl builds such as Strawberry Perl against MSYS2
Perl or Cygwin Perl. In my investigation into an issue I was facing[^1],
I noticed that under MSYS2:
- `/mingw64/bin/perl (This is perl 5, version 22, subversion 0 (v5.22.0) built for MSWin32-x64-multi-thread)`
was NOT able to use `open('...')` on a long path.
- `/usr/bin/perl (This is perl 5, version 22, subversion 1 (v5.22.1) built for x86_64-msys-thread-multi)`
was able to use `open('...')` on a long path.
Similarly, I am able to use `open(...)` on a Unicode filename using the
MSYS2 `/usr/bin/perl`, but with `/mingw64/bin/perl`, I get the error
"Invalid argument".
I presume that the msys2-runtime uses the wide-character API underneath.
Cheers,
- Zaki Mughal
[^1] Details here: <https://github.com/plicease/Alien-Build/issues/13>.
>
>
> --
> perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous