fix: fall back to copy when hard links fail in pnpm linker#7067
fix: fall back to copy when hard links fail in pnpm linker#7067VforVitality wants to merge 1 commit intoyarnpkg:masterfrom
Conversation
| if (shouldFallbackToCopy(err)) { | ||
| const content = await destinationFs.readFilePromise(indexPath); | ||
| await destinationFs.writeFilePromise(destination, content); | ||
| if (sourceMode !== defaultMode) |
There was a problem hiding this comment.
Missing curly bracket
| if (sourceMode !== defaultMode) | |
| if (sourceMode !== defaultMode) { |
| import {NodeFS} from '../sources/NodeFS'; | ||
| import {xfs, PortablePath, ppath, Filename, npath} from '../sources'; |
There was a problem hiding this comment.
Linter fix
| import {NodeFS} from '../sources/NodeFS'; | |
| import {xfs, PortablePath, ppath, Filename, npath} from '../sources'; | |
| import {NodeFS} from '../sources/NodeFS'; | |
| import {xfs, ppath, Filename} from '../sources'; |
|
@VforVitality it would be nice to get this done. It would probably fix an issue I see when hard linking files from outside of a docker into the image. |
VforVitality
force-pushed
the
fix/5326-pnpm-linker-hardlink-fallback
branch
from
bd34268 to
98ae0a7
Compare
|
Hi @tobiasweibel The thing is that we started using a 'same-way-patched' yarn (4.7.0 in our case) and even though it works with the fallback, we experienced some performance degradation on ntfs. So I went deeper with my research and turned out that I'm only not sure if this improvement should be a part of this PR? Anyone, any opinion? Shall it just fix the issue or also to try to improve performance a bit? |
When using nodeLinker: pnpm, the content-addressable index creates hard links from the index to node_modules/.store/. This fails in several scenarios: - EXDEV: index and project on different volumes (common in Docker, CI, and Windows multi-drive setups) - EMLINK: inode hard link limit exceeded (Linux/macOS) - UNKNOWN (link syscall): NTFS hard link limit of 1024 per file (Windows); libuv does not map ERROR_TOO_MANY_LINKS to EMLINK - EPERM (link syscall): insufficient privileges for hard links This commit adds a shouldFallbackToCopy() helper that detects these errors, and wraps the linkPromise call in copyFileViaIndex() with a try/catch that gracefully degrades to copying the file content. This matches the behavior of the real pnpm CLI. Fixes yarnpkg#5326
VforVitality
force-pushed
the
fix/5326-pnpm-linker-hardlink-fallback
branch
from
98ae0a7 to
e311aff
Compare
3 participants
Summary
When using
odeLinker: pnpm, the content-addressable index creates hard links from the global index to
ode_modules/.store/. This fails in several common scenarios:
This PR adds graceful degradation: when \linkPromise\ fails with any of these errors, the file content is copied from the index instead. This matches the behavior of the real pnpm CLI, which also falls back to copying.
Changes
Testing
Unit tests
All 8 test suites pass (104 passed, 5 platform-skipped):
\
yarn test:unit yarnpkg-fslib # ✅ 8 passed, 0 failed
\\
Real-world validation
Tested against a large monorepo (~40 workspaces) with @mui/icons-material\ (~17,000 .d.ts\ files with identical content hashing to the same index entry):
Fixes #5326