Files with very long paths fail to extract on Windows

[sgtcoolguy]

Cookbook version

2.0.2

Chef-client version

12.16.42

Platform Details

Windows 10

Scenario:

Attempting to use ark to grab a 7z file (https://sourceforge.net/projects/boost/files/boost/1.62.0/boost_1_62_0.7z) and extract it to C:\Program Files(x86)\boost

The boost libraries generate very long paths, beyond Windows old path limits. Using copy to copy files from the temp dir over when stripping components ends up failing because of these long paths.

Looks like using Robocopy in place of copy would work? Or possibly prefixing the path with \\?\:
http://superuser.com/questions/216704/how-to-copy-files-that-have-too-long-of-a-filepath-in-windows/760601

Steps to Reproduce:

ark 'boost' do
  url "https://sourceforge.net/projects/boost/files/boost/1.62.0/boost_1_62_0.7z"
  extension '7z'
  version '1.62.0'
  checksum 'b91c2cda8bee73ea613130e19e72c9589e9ef0357c4c5cc5f7523de82cce11f7'
  win_install_dir 'C:\\Program Files (x86)\\boost'
end

Expected Result:

I expect the file to get downloaded, the directory to get created, the contents extracted inside.

Actual Result:

==> default: Sub items Errors: 1
==> default: STDERR: ERROR: Can not open output file : The system cannot find the path specified. : C:/Users/vagrant/AppData/Local/Temp/d20161117-4888-1kdq1qm\boost_1_62_0\libs\geometry\doc\html\geometry\reference\spatial_indexes\boost__geometry__index__rtree\rtree_parameters_type_const____indexable_getter_const____value_equal_const____allocator_type_const___.html
==> default: ---- End output of "c:\Program Files\7-Zip\7z.exe" x "C:/chef/cache/boost-1.62.0.7z" -aoa -o"C:/Users/vagrant/AppData/Local/Temp/d20161117-4888-1kdq1qm" -uy && for /f %1 in ('dir /ad /b "C:\Users\vagrant\AppData\Local\Temp\d20161117-4888-1kdq1qm"') do "C:\Windows\System32\xcopy" "C:\Users\vagrant\AppData\Local\Temp\d20161117-4888-1kdq1qm\%1" "C:\Program Files (x86)\boost" /s /e ----
==> default: Ran "c:\Program Files\7-Zip\7z.exe" x "C:/chef/cache/boost-1.62.0.7z" -aoa -o"C:/Users/vagrant/AppData/Local/Temp/d20161117-4888-1kdq1qm" -uy && for /f %1 in ('dir /ad /b "C:\Users\vagrant\AppData\Local\Temp\d20161117-4888-1kdq1qm"') do "C:\Windows\System32\xcopy" "C:\Users\vagrant\AppData\Local\Temp\d20161117-4888-1kdq1qm\%1" "C:\Program Files (x86)\boost" /s /e returned 2

[sgtcoolguy]

The ?\ hack doesn't work, but robocopy does - sort of. The issue is that robocopy gives non-zero exit codes for normal use cases. See http://superuser.com/questions/280425/getting-robocopy-to-return-a-proper-exit-code

Likely needs more hacking to wrap the robocopy command and convert exits code less than 1 (or 4?) into 0.