Unable to restore symlinks from cache on Windows

[jonkoops]

We noticed that since version 3.2.1 of actions/cache that our CI jobs have started failing. This seems to be caused by the inability to restore symbolic links, resulting in the following output in our failing job:

/usr/bin/tar: node_modules/.bin/acorn: Cannot create symlink to '../acorn/bin/acorn': No such file or directory
/usr/bin/tar: node_modules/.bin/pidtree: Cannot create symlink to '../pidtree/bin/pidtree.js': No such file or directory
/usr/bin/tar: Exiting with failure status due to previous errors
Warning: Failed to restore: "C:\Program failed with error: The process 'C:\Program Files\Git\usr\bin\tar.exe' failed with exit code 2

Reverting back to version 3.2.0 seems to resolve the issue, allowing the CI to pass again.

[Phantsure]

@jonkoops It looks like the workflow is not using npm cache like suggested here https://github.com/actions/cache/blob/main/examples.md#node---npm and the keys are not OS specific. You may use any one of those solutions to keep using latest v3 for now.
We are looking into this specific issue. Reason for this issue is, on windows, cache restore step is restoring cache saved on linux/mac runners and symlinks don't work due to path differences in windows and *-unix like systems.

[danyeaw]

We ran in to a similar problem here: gaphor/gaphor#1950

Run actions/cache/restore@v3.2.1
  with:
    path: C:\gtk-build\gtk\x64\release\**
    key: gvsbuild-2-2022.6.0
Received 107917093 of 107917093 (100.0%), 122.4 MBs/sec
Cache Size: ~103 MB (107917093 B)
"C:\Program Files\Git\usr\bin\tar.exe" -xf D:/a/_temp/c81337b8-6bf0-43b0-a4ff-d4826b0628e0/cache.tzst -P -C D:/a/gaphor/gaphor --force-local --use-compress-program "zstd -d"
/usr/bin/tar: C\:/gtk-build/gtk/x64/release/etc/fonts/conf.d/10-hinting-slight.conf: Cannot create symlink to '/c/gtk-build/gtk/x64/release/share/fontconfig/conf.avail/10-hinting-slight.conf': No such file or directory

Is there a way to disable this cross-os caching? This cache step is specific to a library being built on Windows.

[jonkoops]

@Phantsure Yeah, looks like adding the OS to the cache key fixes this issue. This does however still seem like a breaking change that was introduced in a patch version.

[bishal-pdMSFT]

Version 3.2.1 has been reverted and this issues should be gone now. We are evaluating options on how to fix issue of symbolic links across OS.