Lovepreet Singh

Hi @Adnn @wrexbe @mattjohnsonpint, we do understand. Actually `zstd` is disabled on Windows due issues with bsd tar, hence the slowness of restore. While we look into it, you could...

👋 @rfay, We have added the `zstd` requirement to documentation when using self-hosted runners [here](https://github.com/actions/cache/blob/main/workarounds.md#improving-cache-restore-performance-on-windowsusing-cross-os-caching). Closing this issue. Feel free to reopen if you have followup questions.

Hi @shichen85 @coreysharris @Safihre . As @aminya observed, `zstd` is disabled on Windows due issues with bsd tar. We are working on a longer term solution. You could meanwhile use...

@Safihre could you share your workflow file or the sample run or logs if possible?

@Safihre I'm not sure what the issue is. I tried running a similar albeit simpler workflow to yours using the `syphar/[email protected]` action but still found windows to be reasonably fast...

Hi @rfay, the tar compression(zstd) on Windows while using the above workaround should now work. Please test and let us know if the issue is now resolved.

Closing the issue since a fix has been deployed and tested. Feel free to re-open if recurs.

@rfay we are adding the above workaround to the docs and will also document installation of `zstd` for windows self-hosted runners. If you are only using Windows self-hosted runners and...

Hi @GC-Configit, I see you are using this step as a workaround. ``` - if: ${{ runner.os == 'Windows' }} # Workaround required when using cache action across operating systems....

@GC-Configit @mladedav, so without using the workaround(using gnu tar instead of bsd tar in windows), the expected behaviour is caching on windows can cause a different cache save even with...