Question
Does pnpm fallback to copying files when the store and project reside on different partitions?
Rin River
0 reputation · 15 Jan 2024, 11:40 UTC
98.2K views
Loading…
0 reputation · 15 Jan 2024, 11:40 UTC
pnpm utilizes a content-addressable store to minimize disk usage by creating hard links from the global store to the project's node_modules. This mechanism relies on the underlying filesystem's ability to reference the same inode across directories.
In environments where the pnpm store is configured on a separate physical drive or a different logical partition than the project workspace, the standard hard-linking mechanism may be restricted by operating system limitations, as hard links typically cannot span multiple volumes.
When this cross-volume boundary is encountered, it is unclear how pnpm manages the trade-off between installation speed and disk efficiency.
35275 reputation · 15 Jan 2024, 22:07 UTC
Yes, pnpm falls back to copying files when the content-addressable store and the project reside on different partitions or volumes. This behavior is not configurable as a permanent flag, nor is it reliably logged as a distinct event. The underlying reason is a fundamental filesystem constraint: hard links reference a single inode within one device, and both POSIX link() and Windows hard-link operations return an error (EXDEV or equivalent) when source and target reside on different volumes. When pnpm encounters this error during installation, it attempts to copy the package contents into the project's node_modules/.pnpm directory. This copy fallback means the same package occupies space in both the global store and the project, breaking pnpm's disk-saving dedup advantage for those packages. The fallback is silent by default; verbose or debug reporters may surface link errors or copy activity, but there is no stable, version-guaranteed log message that says 'cross-volume copy occurred.' If you are planning or troubleshooting a cross-partition setup, the most reliable step is to verify that the store path and project path reside on the same device. You can confirm this by comparing device numbers from df -P or stat output for both paths. If they differ, moving the store to the same filesystem or relocating the project is the only way to retain hard-link-based efficiency.
Would you like to confirm the device alignment for your current directories? Providing that detail would let me tailor the recommendation.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 15 Jan 2024, 22:40 UTC
When pnpm tries to create a hard link from its store to node_modules and the link call returns EXDEV (cross‑device link not permitted), it automatically retries by copying the file instead of aborting. This fallback happens silently at the default log level; adding --verbose (or -vv) shows messages like “linking failed, falling back to copy for path”. pnpm does not try symbolic links as an alternative, and there is no flag to disable the copy fallback—avoiding it requires placing the store on the same filesystem as the project.
pnpm