Ark fails to compile on Windows if 7zip is not already installed

[sprokopiak]

I think #153 introduced a bug in version 1.2.0.

In my Vagrant box, 7zip is not pre-installed. In attributes/default.rb, lines 25-26 were added to look for the location of 7zip in the registry. However, it fails if the registry key is not found.

Installing 7zip before running Ark fixes the problem.

I thought Ark was supposed to install 7zip if it did not exist, but now Ark is failing at compile time before it would have a chance to download and install 7zip.

[pinterl]

This change broke our server deployment process, we could not launch any Windows servers where any of the cookbooks referenced the Ark cookbook.

Luckily Berkshelf caches the referenced cookbooks on the workstation, so I could modify the Ark cookbook and upload my version to the Chef server.

As a temporary solution I have updated the Ark attribute file
C:\Users\MY-USERNAME.berkshelf\cookbooks\ark-1.2.0\attributes\default.rb

Replaced

when 'windows'
  "\"#{::Win32::Registry::HKEY_LOCAL_MACHINE.open(
  'SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\7zFM.exe', ::Win32::Registry::KEY_READ).read_s('Path')}\\7z.exe\""

with

when 'windows'
  'C:\\Program Files\\7-Zip\\7zFM.exe'

and uploaded the cookbooks to the Chef server with
berks upload --no-freeze

[rjaros87]

👍

[mlcooper]

Downgrading to v1.1.0 is my current workaround; the registry method in the default attributes file is not included in this version.

[jjohnson-axway]

As previously stated this fails at compile time.
I've had other cookbooks that depend on ark but don't actually need 7zip to execute.
I worked around this issue by adding rescue nil. Of course if you actually need 7zip later this won't help.

In cookbooks\ark\attributes\default.rb

default['ark']['tar'] = case node['platform_family']
                          when 'windows'
                          "\"#{::Win32::Registry::HKEY_LOCAL_MACHINE.open(
                            'SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\7zFM.exe', ::Win32::Registry::KEY_READ).read_s('Path')}\\7z.exe\"" rescue nil
                        when 'mac_os_x', 'freebsd'
                          '/usr/bin/tar'
                        when 'smartos'
                          '/bin/gtar'
                        else
                          '/bin/tar'
                        end

[axos88]

Would putting it into a lazy {} block help?

[nwatnick]

👍

[sgtcoolguy]

I don't think a lazy block would help. I think the fix looks like it'd be to rescue nil so that when 7-zip isn't yet installed the ['ark']['tar'] value becomes nil, and then in ark/sevenzip_command_builder.rb to check for a nil value in the sevenzip_binary method and fall back to trying to grabbing the value from registry if nil (and caching the new value if valid).

[sgtcoolguy]

#160 looks to fix this issue. I created a a patched for for my own usage with a similar though slightly less advanced fix. Any chance we can get #160 over the hump?

[tas50]

This should be fixed in the 2.1 release. Let me know if you're still having issues though

[sgtcoolguy]

@tas50 Well, this fixes this particular issue, but I'm seeing plenty of other Windows-related issues and have filed a number of PRs/issues on them.

Issues:

• When using 7zip to extract with strip_components >= 1 (default is 1) extracts to home_dir, not path #164
• Default owner of 'root' fails on Windows #168
• Files with very long paths fail to extract on Windows #169

PRs:

• Sniff .7z file extensions #161
• Fix #164 - When using 7zip to extract with strip_components >= 1 (default is 1) extracts to home_dir, not path #165
• Always quote the sevenzip_binary path and path to xcopy. #166
• Fix #138 - Use x to extract with 7-zip, not e. Use e only for dump, which strips directories. #167

[reijop]

This also introduces a new issue for me as well. The Seven-zip executable is not quoted, so we end up with a command-not-found situation. This is now tracked under issue #172

       ---- Begin output of c:\Program Files\7-Zip\7z.exe e "C:\Users\CLOUD-~1\AppData\Local\Temp\kitchen\cache/machineagent-bundle-64bit-windows-4.2.6.1.zip" -o"C:/Users/CLOUD-~1/AppData/Local/Temp/d20161117-2248-1w0z7wo" -uy && for /f %1 in ('dir /ad /b "C:\Users\CLOUD-~1\AppData\Local\Temp\d20161117-2248-1w0z7wo"') do C:\Windows\System32\xcopy "C:\Users\CLOUD-~1\AppData\Local\Temp\d20161117-2248-1w0z7wo\%1" "" /s /e ----
       STDOUT:
       STDERR: 'c:\Program' is not recognized as an internal or external command,
       operable program or batch file.

[sgtcoolguy]

@reijop I opened PR #166 for exactly that issue. I have a fork and branch with all of the PRs/issues I ran into above fixed on it, https://github.com/sgtcoolguy/ark/tree/axway in case you need a working version until all of them get sorted/merged.