Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The PATH has changed on Windows, and the Git shell tar is used instead of Windows tar #480

Closed
1 of 5 tasks
eregon opened this issue Feb 28, 2020 · 16 comments
Closed
1 of 5 tasks
Assignees
Labels

Comments

@eregon
Copy link

eregon commented Feb 28, 2020

Describe the bug

The PATH has changed on Windows in the last 24 hours.
ruby/setup-ruby#28 has all the details.

Basically, any tar command ran on Windows now uses
C:\Program Files\Git\usr\bin\tar.exe
instead of previously
C:\windows\system32\tar.exe.

That includes actions/tool-cache's extractTar().

The first tar.exe seems mostly broken with Windows-like paths, and gives

"C:\Program Files\Git\usr\bin\tar.exe" xz -C C:\Users\runneradmin\.rubies -f d:\a\_temp\faffe4a1-577f-4d8d-912c-b897e86696ba
tar (child): Cannot connect to d: resolve failed

We can see the PATH changed in
https://github.com/ruby/jruby-dev-builder/runs/470590213?check_suite_focus=true (working)
https://github.com/ruby/jruby-dev-builder/runs/473104647?check_suite_focus=true (failing)
Differences:

--- a/old
+++ b/new
@@ -8,10 +8,12 @@ C:\hostedtoolcache\windows\Boost\1.72.0
 C:\Program Files\dotnet
 C:\mysql-5.7.21-winx64\bin
 C:\Program Files\Java\zulu-8-azure-jdk_8.40.0.25-8.0.222-win_x64\bin
+C:\SeleniumWebDrivers\GeckoDriver
 C:\Program Files (x86)\sbt\bin
 C:\Rust\.cargo\bin
 C:\Go1.12.7\bin
 C:\Program Files\Git\bin
+C:\Program Files\Git\usr\bin
 C:\hostedtoolcache\windows\Python\3.7.6\x64\Scripts
 C:\hostedtoolcache\windows\Python\3.7.6\x64
 C:\npm\prefix
@@ -24,10 +26,10 @@ C:\windows\System32\OpenSSH\
 C:\ProgramData\Chocolatey\bin
 C:\Program Files\Docker
 C:\Program Files\PowerShell\6\
-C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\
 C:\Program Files\dotnet\
 C:\Program Files\Microsoft SQL Server\130\Tools\Binn\
 C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\
+C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\
 C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code
 C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager
 C:\Program Files\nodejs\
@@ -39,11 +41,11 @@ C:\Program Files (x86)\sbt\bin
 C:\Program Files (x86)\Subversion\bin
 C:\SeleniumWebDrivers\ChromeDriver\
 C:\SeleniumWebDrivers\EdgeDriver\
-C:\ProgramData\chocolatey\lib\maven\apache-maven-3.6.2\bin
+C:\ProgramData\chocolatey\lib\maven\apache-maven-3.6.3\bin
 C:\Program Files\CMake\bin
 C:\Strawberry\c\bin
 C:\Strawberry\perl\site\bin
 C:\Strawberry\perl\bin
 C:\Program Files\OpenSSL\bin
 C:\Users\runneradmin\.dotnet\tools
-C
+C:\Pro

Area for Triage:

Question, Bug, or Feature?:
Bug

Virtual environments affected

  • macOS 10.15
  • Ubuntu 16.04 LTS
  • Ubuntu 18.04 LTS
  • Windows Server 2016 R2
  • Windows Server 2019

Expected behavior

extractTar() and tar in the default shell should work on Windows with Windows paths (e.g., C:...).

Actual behavior

It breaks as shown above.

@eregon
Copy link
Author

eregon commented Feb 28, 2020

Gist with the full output for PATH before and after:
https://gist.github.com/eregon/1f1e0d4171cdaa162da0998df5f1f6d2

The last entry, C:\Pro (and C before) look weird.

@miketimofeev
Copy link
Contributor

@eregon it's the result of
#282 and #415
Windows tar.exe can't untar xz archives, unfortunately.

@eregon
Copy link
Author

eregon commented Feb 28, 2020

And Git's tar cannot deal with Windows paths with a drive name, which seems an even larger problem as tar no longer work in the default shell.
How should this be solved then?

@miketimofeev
Copy link
Contributor

@eine is it critical for you to use tar instead of 7z?

@eregon
Copy link
Author

eregon commented Feb 28, 2020

Another bug of the Git shell tar is, if the archive contains foo.exe and foo, it only extracts one of them and just ignores the other one!
That was extremely confusing in MSP-Greg/setup-ruby#1
My advice is therefore: never use the Git shell tar.

@miketimofeev
Copy link
Contributor

@eregon yeah, that makes sense. We've rolled back the changes and will deliver the fixed image next week.

@miketimofeev miketimofeev added Area: Common Tools awaiting-deployment Code complete; awaiting deployment and/or deployment in progress bug Something isn't working OS: Windows and removed Area: Packages needs triage labels Mar 1, 2020
@miketimofeev
Copy link
Contributor

@eregon The changes have been delivered. Closing the issue, but feel free to reopen if you have any concerns.
Thank you!

@miketimofeev miketimofeev removed the awaiting-deployment Code complete; awaiting deployment and/or deployment in progress label Apr 2, 2020
@eregon eregon changed the title The PATH has changed on Windows, and Git shell tar is not used instead of Windows tar The PATH has changed on Windows, and the Git shell tar is used instead of Windows tar Apr 2, 2020
@ihnorton
Copy link

Is there now no tar built-in support? I am getting tar: command not found in bash script sections running on both vs2017 amd macOS-10.15 images.

@miketimofeev
Copy link
Contributor

@ihnorton hmm, both work just fine for me now.

jobs:
  job1:
    runs-on: vs2017-win2016
    steps:
      - uses: actions/checkout@v2
      - name: check tar
        run: |
          tar --version
        shell: bash
  job2:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v2
      - name: check tar
        run: |
          tar --version
        shell: bash

@ihnorton
Copy link

My mistake, thanks.

@Holzhaus
Copy link

Holzhaus commented Nov 23, 2020

The issue persists in windows-2016, see actions/cache#333. Please reopen.

@maxim-lobanov
Copy link
Contributor

@Holzhaus , It is expected behavior for windows-2016 image.
WindowsServer 2016 doesn't contain Windows tar. It is distributed by Windows itself and was added only in Windows2019.
So on Windows 2016 there is no any other tar except Git Tar.

@eine
Copy link

eine commented Nov 24, 2020

So on Windows 2016 there is no any other tar except Git Tar.

@maxim-lobanov, MSYS2's tar is also available on either Windows 2016 or Windows 2019, isn't it?

@maxim-lobanov
Copy link
Contributor

@eine , as far as I know, actions/cache doesn't work with MSYS tar: actions/toolkit#632

@Holzhaus
Copy link

So actions/cache is completely non-functional on windows-2016 because there is no tar.exe that can work with windows paths?

@eine
Copy link

eine commented Nov 24, 2020

@Holzhaus, I suggest subscribing to actions/toolkit#632.

egor-tensin added a commit to egor-tensin/cmake-common that referenced this issue Mar 14, 2021
actions/cache@v2 doesn't work on windows-2016 images, since those
contain the GNU tar, which cannot work with \ as path separator.  This
was fixed in package @actions/cache v1.0.5, which is used by action
actions/[email protected] [1][2].

In addition, it simply couldn't find tar.exe on those images thanks to
my action cleanup-path, which removed the corresponding directory (I
think it was Git's bin/) from PATH.  It worked for windows-2019 images
thanks to them containing tar.exe in System32.  Solved by turning
cleanup-path into a JavaScript action with a "post" step, which restores
the original PATH value.

[1]: actions/runner-images#480
[2]: actions/toolkit#632
nil4 added a commit to royalapplications/royalvnc that referenced this issue Oct 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants