Describe the bug

BSD tar has been problematic for the caching action for several reasons:

1. bsdtar does not handle recursive directory structures created by junction points - Tar fails on Windows after 15min due to symlink cycle cache#315

2. bsdtar does not work with zstd compression, causing the process to hang - zstd compression hanging on Windows with large files cache#301

3. Changing the PATH will cause the cache to switch between BSD tar and GNU tar causing compatibility issues on Windows (due to the zstd compression bug) - Robustness bug - cache restore finds nothing even though cache was saved successfully (Windows) cache#465

4. BSD tar on MacOS corrupting executables and.dylib files - Unable to restore C++ artifacts in some situations cache#460 and Cached data restored from Rust's Cargo build is corrupted cache#403

On hosted runners, tar.exe is available in several locations locations:

1. BSD tar - C:\Windows\System32\tar.exe (Windows 2019 only)
2. GNU tar - C:\Program Files\Git\usr\bin\tar.exe
3. GNU tar - C:\msys64\usr\bin\tar.exe

Caching correctly selects GNU tar on Windows 2016 runners, since (2) shows up on the PATH. Windows 2019 runners use BSD tar because (1) shows up first on the PATH. (3) does not appear on the system PATH so it is never selected.

Given the problems with bsdtar, it seems we should either ensure GNU tar appears first on the system PATH or improve the lookup logic in the caching module to find GNU tar. Right now, a workaround is to explicitly set the system PATH:

    - name: Use GNU Tar from Msys
      if: ${{ runner.os == 'Windows' }}
      run: |
        echo "::add-path::C:\msys64\usr\bin"

Expected behavior
GNU tar is selected if it is available.

Desktop (please complete the following information):

• OS: Windows