[Bug?]: Error: EXDEV: cross-device link not permitted

[Climenty]

Self-service

• I'd be willing to implement a fix

Describe the bug

Any yarn dlx command ends with error on Linux because it tries to link tmp file system and local one.

To reproduce

yarn dlx @yarnpkg/sdks vscode (for example)

Result:

➤ YN0000: · Failed with errors in 3s 660ms                                        
node:internal/process/promises:391                                                
    triggerUncaughtException(err, true /* fromPromise */);
    ^                                                                             
[Error: EXDEV: cross-device link not permitted, link '/home/xxx/.yarn/berry/i
ndex/52/5220208b882bf713918c25d953de5127c523db71.dat' -> '/tmp/xfs-3c6297d8/dlx-30
676/node_modules/.store/@yarnpkg-sdks-npm-3.2.0-03b1f3c8a8/package/README.md'] {
  errno: -18,                                                                     
  code: 'EXDEV',                                                                  
  syscall: 'link',                                                                
  path: '/home/xxx/.yarn/berry/index/52/5220208b882bf713918c25d953de5127c523db71.dat',
  dest: '/tmp/xfs-3c6297d8/dlx-30676/node_modules/.store/@yarnpkg-sdks-npm-3.2.0-03b1f3c8a8/package/README.md'                                                      
}

Environment

System:
Linux OpenSuse Leap 15.6 (6.4.0 kernel)
Binaries:
Node.js v20.15.1
Yarn 4.4.0

Additional context

It is really simple error, read how-to-fix-nodejs-error-exdev for workaround.

[clemyan]

Looks like a duplicate of #6497? See #6497 (comment)

[Climenty]

Looks like a duplicate of #6497? See #6497 (comment)

Yes, the source of problem is the same - hardlinks. But we should not use links between temporary folder and any other at all, cause temporary partition may has different file system by design.

[yarnbot]

Hi! 👋

It seems like this issue as been marked as probably resolved, or missing important information blocking its progression. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it.

[clemyan]

The problem is you are explicitly requesting two conflicting constraints for Yarn:

1. Hardlink all packages to the global store
2. Install this package into the temp folder

Do we ignore one of them? If so, which one?

If we ignore 1, all dlx calls will use up much more space in the temp folder. This may be unexpected to the user given they expect packages to hardlink to the global store, and may cause problems given that some systems do not clean the temp folder by default.

If we ignore 2, then where do we install the package?

---

In more general terms, the problem is using an install strategy that involves hardlinking to a global store system-wide, when projects on that system are spread across multiple devices.

FWIW pnpm also suffers from it, but they solved it simply by having multiple stores. Personally I don't think just putting stuff everywhere is a great solution, especially given that it is happening silently.

Maybe we can add a config for users to opt into that behavior?

cc @frg2089

[Climenty]

In more general terms, the problem is using an install strategy that involves hardlinking to a global store system-wide, when projects on that system are spread across multiple devices.

@clemyan, you are absolutely right. This part from pnpm FAQ tells the same: "The package store should be on the same drive and filesystem as installations, otherwise packages will be copied, not linked. This is due to a limitation in how hard linking works, in that a file on one filesystem cannot address a location in another."

The current problem with yarn - trying to use link without checking for error condition. The right behavior - break installation process from the start with warning message that your project and package storage are on different devices/FS and could not be linked.

And the user should decide for himself - move project or storage location. But I want to return to an important point once again. When a user choose another drive for both places, we should NOT use link mechanic from Temp folder to outside, cause it is 100% that temporary folder on another drive (or filesystem volume).