Version 3.3.2 fails to save cache on self-hosted windows runner

I am trying to cache data with version 3.3.2, but it fails to save the data to the cache with an error. The runner is a self-hosted windows runner for a GitHub Enterprise Server 3.10.3 instant.

This is the step being used to cache the data.

    - name: Cache Data
      id: cache-data
      uses: actions/cache@v3.3.2
      with:
        path: dynamic
        key: myfile-dynamic6

This is the Post Cache Data error message:

Post job cleanup.
"C:\Program Files\Git\usr\bin\tar.exe" --posix -cf cache.tgz --exclude cache.tgz -P -C C:/actions-runner/_work/MyCode/MyCode --files-from manifest.txt --force-local -z
/bin/sh: line 1: gzip: command not found
/usr/bin/tar: Child returned status 127
/usr/bin/tar: Error is not recoverable: exiting now
Warning: Failed to save: "C:\Program failed with error: The process 'C:\Program Files\Git\usr\bin\tar.exe' failed with exit code 2

If I use version v3.2.2 instead of v3.3.2 the cache file looks like it's created. At least it shows up in the Actions | Caches menu, and I see it has a byte size that changes as the content changes. The problem with the v3.2.2 version is that it fails to be restored.

This is the step that successful saves.

    - name: Cache Data
      id: cache-data
      uses: actions/cache@v3.2.2
      with:
        path: dynamic
        key: myfile-dynamic6

This is the step to restore.

    - name: Restore cached
      uses: actions/cache/restore@v3.2.2
      with:
        path: dynamic
        key: myfile-dynamic6

This is the message saying failed to restore because it couldn't find the input key.

Run actions/cache/restore@v3.2.2
  with:
    path: dynamic
    key: myfile-dynamic6
Warning: Failed to restore: 
Cache not found for input keys: myfile-dynamic6

This is a screenshot showing that the cache exits with the expected key.

Is there anything more I can do to debug this issue as to why it fails to find the expected key in version 3.2.2? Is there a bug in 3.3.2 for windows runners that use the cache?

Thanks,
Justin

Start by reproducing the workflow using actions/cache@v3.3.2 on a self-hosted Windows runner, then compare it with v3.2.2. Investigate the reported tar.exe and missing gzip output; done means the cache saves and restores with the expected key without warnings.