permission issue causing failure to cache on windows

[geemus]

Description:
Post job cleanup fails with permission issues:

Post job cleanup.
"C:\Program Files\Git\usr\bin\tar.exe" --posix -cf cache.tzst --exclude cache.tzst -P -C D:/a/anchor/anchor --files-from manifest.txt --force-local --use-compress-program "zstd -T0"
/usr/bin/tar: C\:/npm/cache/_logs/2024-04-29T15_30_50_704Z-debug-0.log: Cannot open: Permission denied
/usr/bin/tar: C\:/npm/cache/_logs/2024-04-29T15_30_59_272Z-debug-0.log: Cannot open: Permission denied
/usr/bin/tar: Exiting with failure status due to previous errors
Warning: Failed to save: "C:\Program failed with error: The process 'C:\Program Files\Git\usr\bin\tar.exe' failed with exit code 2

Action version:
actions/setup-node@v4

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
node 20.10.0
npm (? I didn't specify, so the default I suppose)

Repro steps:
Here are what I think would be the relevant bits from our setup:

      - name: Setup Node (prism)
        uses: actions/setup-node@v4
        with:
          cache: npm
          node-version-file: '.tool-versions'
      - run: npm install

I'll note that we just have a package.json and no lock at present in case that is relevant.

Expected behavior:
I expected the caching to "just work" with this setup, as it does with the same invocation on mac/ubuntu.

Actual behavior:
Setup node and the rest of the action work fine, but the cleanup/caching fails (so there is never a cache to be used).

[aparnajyothi-y]

Hello @geemus, Thank you for creating this issue and we will look into it :)

[priya-kinthali]

Hello @geemus 👋,
Thank you for sharing the details!
I tried to replicate the error using the provided code snippet, but was unable to do so. By default, the actions/setup-node action looks for a dependency lock file in your repository's root. If this file is not found, the setup step will fail. You can find more information in this related document.
As I couldn't reproduce your issue, it would be really helpful if you could share a link to a minimal reproduction of the problem for further investigation. Thank you in advance:)

[geemus]

Thanks for checking on this. I changed some things to ensure there is a lock file present, but it doesn't seem to have made a difference. FWIW we run the same jobs on mac and ubuntu and they worked fine both before and after (and everything but the cache save afterward seems to work on windows). I also tried to setup a minimal reproduction case, but so far I haven't figured out how to get it to fail (it seems to work just fine, probably similar to what you saw).

[priya-kinthali]

Hello there👋,
Any luck creating a reproducible scenario? This would greatly help us in diagnosing and fixing the issue. Thanks in advance for your cooperation:)

[geemus]

It's still happening consistently in our main repo, but I have been unable to extract the right mix of things to get it to reproduce elsewhere so far.

[priya-kinthali]

Hello @geemus 👋,
Your efforts to create a minimal reproduction case are much appreciated:)
In the meantime, for troubleshooting purposes, please consider the following:

1. Review the permission settings for the directories and files being accessed during the cleanup process. The error messages suggest that there are difficulties opening certain log files due to permission constraints.
2. Confirm that no other processes are accessing the log files. Close any processes using these files prior to the start of the cleanup job. This is important because, on Unix-like systems like macOS and Ubuntu, file locking is advisory, meaning other processes can access a file even if it's already in use. Conversely, on Windows, file locking is mandatory, preventing other processes from accessing a file in use. The 'Permission denied' error typically arises in these scenarios.

Hope this helps!

[geemus]

Thanks, those are good pointers. Since it is a monorepo, I wonder if perhaps other things are claiming a lock on that directory such as you suggest (like perhaps the go-setup stuff). I'll try to look at my reproduction efforts again and see if I can figure something out soon.