ArchiveTar plugin may fail on long filenames

[plicease]

As reported here:

https://metacpan.org/source/ZMUGHAL/Alien-MuPDF-0.007_02/alienfile#L15

            # Using CommandLine to extract rather than ArchiveTar because
            # the extraction using ArchiveTar is not always successful on
            # Windows.  This can happen because the mupdf tarball contains
            # long paths that can push the entire path over the 260
            # character path limit.

[zmughal]

Summary:

• The only binaries that seem to support long paths natively on Windows are those under the MSYS2 subsystem: /usr/bin/perl, /usr/bin/bsdtar.

• The binaries that call the libc APIs directly such as the mingw64's /mingw64/bin/perl and Strawberry C:\Strawberry\perl\bin\perl.exe are limited by MAX_PATH.

---

The bug I'm seeing happens on MSYS2 because the MSYS2 distribution uses a deep directory structure that pushes some of the MuPDF absolute path names over the 260 character limit of MAX_PATH:

This is with MSYS2's /mingw64/bin/perl (This is perl 5, version 22, subversion 0 (v5.22.0) built for MSWin32-x64-multi-thread):

C:\msys64\home\zaki\.cpanm\work\1494265370.19992\Alien-MuPDF-0.007_01\_alien\download_E5uH $ /mingw64/bin/perl -MArchive::Tar -E '$Archive::Tar::DEBUG = 1; my $t = Archive::Tar->new; $t->read("mupdf-1.11-source.tar.gz"); $t->extract("mupdf-1.11-source/thirdparty/harfbuzz/test/shaping/texts/in-tree/shaper-indic/indic/script-devanagari/utrrs/codepoint/IndicFontFeatureCodepoint-DevnagariSpecificAddition.txt")'

Could not open file 'C:\msys64\home\zaki\.cpanm\work\1494265370.19992\Alien-MuPDF-0.007_01\_alien\download_E5uH\mupdf-1.11-source\thirdparty\harfbuzz\test\shaping\texts\in-tree\shaper-indic\indic\script-devanagari\utrrs\codepoint\IndicFontFeatureCodepoint-DevnagariSpecificAddition.txt': No such file or directory at C:/msys64/mingw64/lib/perl5/site_perl/Archive/Tar.pm line 850.
        Archive::Tar::_extract_file(Archive::Tar=HASH(0x76b330), Archive::Tar::File=HASH(0xa417750)) called at C:/msys64/mingw64/lib/perl5/site_perl/Archive/Tar.pm line 649
        Archive::Tar::extract(Archive::Tar=HASH(0x76b330), "mupdf-1.11-source/thirdparty/harfbuzz/test/shaping/texts/in-t"...) called at -e line 1
 at -e line 1.
Could not extract 'mupdf-1.11-source/thirdparty/harfbuzz/test/shaping/texts/in-tree/shaper-indic/indic/script-devanagari/utrrs/codepoint/IndicFontFeatureCodepoint-DevnagariSpecificAddition.txt' at C:/msys64/mingw64/lib/perl5/site_perl/Archive/Tar.pm line 650.
        Archive::Tar::extract(Archive::Tar=HASH(0x76b330), "mupdf-1.11-source/thirdparty/harfbuzz/test/shaping/texts/in-t"...) called at -e line 1
 at -e line 1.

The error occurs at a call to open(...) that uses the full path when extracting and as such affects all versions of Archive::Tar. The MSYS2 /usr/bin/bsdtar does not have this problem which is why I switched to Extract::CommandLine. I haven't investigated the Win32 API syscalls it makes in the end, but I suspect it is using the wide-char versions.

This bug does not occur for me on Strawberry Perl with cpanm since the path to my %USERPROFILE% is not very long. However, the same underlying MAX_PATH bug is still there when I try to extract from the same deep directory path.

I have started a thread on p5p that asks what would need to be done to solve this in perl.

---

I also tried to use ptar on MSYS2 and curiously, it worked where the above perl -MArchive::Tar ... did not. Looking closer, I noticed it was running with the MSYS2 /usr/bin/perl (This is perl 5, version 22, subversion 1 (v5.22.1) built for x86_64-msys-thread-multi). I think this works because I suspect this uses the same MSYS2 APIs as /usr/bin/bsdtar. I also suspect that Cygwin's perl will also do this since the MSYS2-runtime is based off of Cygwin's runtime.

[zmughal]

A small note for future reference: I have been using the MSYS2 /usr/bin/bsdtar (via Extract::CommandLine) for a while now, however the newest version of the source tarball I'm extracting contains a symlink. This causes bsdtar to exit with an error under MSYS2 (error message: Can't create 'filename'). As far as I can tell, this is not being fixed.

[plicease]

@zmughal huh. Out of curiosity does the tar.exe that comes with Windows 10 work any better? That is also bsdtar, but built by Microsoft with their tools presumably.

[zmughal]

No, it does not:

PS C:\Users\vagrant\Downloads> tar xf .\mupdf-1.17.0-source.tar.gz
mupdf-1.17.0-source/thirdparty/freeglut/progs/test-shapes-gles1/android_toolchain.cmake: Can't create '\\\\?\\C:\\Users\\vagrant\\Downloads\\mupdf-1.17.0-source\\thirdparty\\freeglut\\progs\\test-shapes-gles1\\android_toolchain.cmake'
mupdf-1.17.0-source/thirdparty/harfbuzz/README: Can't create '\\\\?\\C:\\Users\\vagrant\\Downloads\\mupdf-1.17.0-source\\thirdparty\\harfbuzz\\README'
tar.exe: Error exit delayed from previous errors.
PS C:\Users\vagrant\Downloads> echo $LASTEXITCODE
1

Also, that tar.exe is not available on older builds of WIndows.

[plicease]

Also, that tar.exe is not available on older builds of WIndows.

We only use tar.exe if it is found, but tbh I care less and less about older builds of Windows as they become unsupported.