Repository navigation
symlink is - stateful? #27795
Description
Version: v11.6.0
Platform: Windows 10 (64bit)
Subsystem: fs
This is easiest to describe with sample code:
let shortPath = 'c:\\temp\\long pathname test';
undefined
let longPath = 'c:\\temp\\long pathname test\\01234567890123456789012345678901234567890123456789\\01234567890123456789012345678901234567890123456789\\01234567890123456789012345678901234567890123456789\\01234567890123456789012345678901234567890123456789\\01234567890123456789012345678901234567890123456789';
undefined
fs.symlinkSync(path.join(shortPath, 'foobar1.jpg'), path.join(longPath, 'foobar1.jpg'));
undefined
fs.symlinkSync(path.join(longPath, 'foobar2.jpg'), path.join(shortPath, 'foobar2.jpg'));
{ Error: EPERM: operation not permitted, symlink ...}
fs.unlinkSync(path.join(longPath, 'foobar1.jpg'))
undefined
fs.symlinkSync(path.join(shortPath, 'foobar1.jpg'), path.join(longPath, 'foobar1.jpg'));
{ Error: EPERM: operation not permitted, symlink ...}
Now there are a few oddities here
a) I can link from a short path to a long one (> MAX_PATH) but not the other way around
b) The error reported is EPERM for some reason, not ENAMETOOLONG or EINVAL
c) after that error has been reported, even the original call linking from short to long fails
c is the most scary of them because it indicates there is some global internal state that gets flipped and breaks all further calls? How does that make sense?
This is independent of the unlink call btw., this problem also happens if I remove the link outside node or if I use a third file.
Activity
gireeshpunathil commentedon Oct 29, 2019
@nodejs/platform-windows
bzoz commentedon May 11, 2020
Reproduces with v14, similar code in plain libuv (two uv_fs_symlink calls) works as expected.
jasnell commentedon May 11, 2020
I do not think this is actually a bug but I think @bnoordhuis would have more context on it (see the old issue nodejs/node-v0.x-archive#6342 for example). Windows handles symlinks oddly and the reason you get an EPERM is that the security configuration actually blocks users from making symlinks in this case. If you change the paths to relative paths within the
cwd, you'll find that the code just works and the symlinks are created. Attempt to do so outside of thecwdand it will fail with EPERM.TanninOne commentedon May 11, 2020
No, it's not a security issue, this happens both when running as admin as well as running in developer mode which allows creation of symlinks with a regular account. As I've written, the error happens due to long paths, it was tested to work with short paths.
And none of that explains problem c, the fact that the function starts behaving differently after it failed once. That can't possibly be intended behavior.
targos commentedon May 11, 2020
It looks like #33351 might fix this.
win,fs: use namespaced path in absolute symlinks
win,fs: use namespaced path in absolute symlinks
win,fs: use namespaced path in absolute symlinks
win,fs: use namespaced path in absolute symlinks