fs: fix fs.rm support for loop symlinks

[nathanael-ruf]

Fixes: #45404

[nathanael-ruf]

The tests have quite a bit of duplicated code (both existing and my new tests). I can add a new block at the bottom of the file that adds the new tests for the sync, async and promise version without so much duplicated code if you want.

[Trott]

The tests have quite a bit of duplicated code (both existing and my new tests). I can add a new block at the bottom of the file that adds the new tests for the sync, async and promise version without so much duplicated code if you want.

For tests only, I generally prefer the repetition. (Ref: https://stackoverflow.com/a/11837973/436641)

[nathanael-ruf]

Thanks for fixing the commit message, one question though: For something like addressing the review comments, should I always amend and force push or is another commit okay for this (I guess you can always squash at the end)?

Also I think the title of the PR is no longer 100% accurate, because deleting invalid links was also broken before (the stat call failed with ENOENT):

nathanael ~/tmp λ tree
.
└── b -> a

nathanael ~/tmp λ node -e 'fs.rmSync("b")'
node:internal/fs/utils:344
    throw err;
    ^

Error: ENOENT: no such file or directory, stat 'b'
    at Object.statSync (node:fs:1538:3)
    at __node_internal_ (node:internal/fs/utils:793:8)
    at Object.rmSync (node:fs:1213:13)
    at [eval]:1:4
    at Script.runInThisContext (node:vm:129:12)
    at Object.runInThisContext (node:vm:305:38)
    at node:internal/process/execution:76:19
    at [eval]-wrapper:6:22
    at evalScript (node:internal/process/execution:75:60)
    at node:internal/main/eval_string:27:3 {
  errno: -2,
  syscall: 'stat',
  code: 'ENOENT',
  path: 'b'
}

The loop thing was just the first issue I encountered.

[aduh95]

should I always amend and force push or is another commit okay for this (I guess you can always squash at the end)?

Pushing more commits is the recommended way, it's a much better experience for folks reviewing the PR as otherwise GitHub is not able to show what's changed since the last review. When landing the PR, we can ask the commit-queue to squash all the commits into the first one, so as long as its commit message is accurate, no need to force push. The other reason to force push would be if you needed to rebase on top of `main`, e.g. to fix a git conflict (merge commits tend to break our tooling).

…

On 13 Nov 2022, at 09:04, Nathanael Ruf ***@***.***> wrote: Thanks for fixing the commit message, one question though: For something like addressing the review comments, should I always amend and force push or is another commit okay for this (I guess you can always squash at the end)? Also I think the title of the PR is not longer 100% accurate, because deleting invalid links was also broken before (the stat call failed with ENOENT): nathanael ~/tmp λ tree . └── b -> a nathanael ~/tmp λ node -e 'fs.rmSync("b")' node:internal/fs/utils:344 throw err; ^ Error: ENOENT: no such file or directory, stat 'b' at Object.statSync (node:fs:1538:3) at __node_internal_ (node:internal/fs/utils:793:8) at Object.rmSync (node:fs:1213:13) at [eval]:1:4 at Script.runInThisContext (node:vm:129:12) at Object.runInThisContext (node:vm:305:38) at node:internal/process/execution:76:19 at [eval]-wrapper:6:22 at evalScript (node:internal/process/execution:75:60) at node:internal/main/eval_string:27:3 { errno: -2, syscall: 'stat', code: 'ENOENT', path: 'b' } The loop thing was just the first issue I encountered. — Reply to this email directly, view it on GitHub <#45439 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADNFTDN6WSRGOPCR5JPUCXDWICOKVANCNFSM6AAAAAAR6O64FQ>. You are receiving this because you commented.

[aduh95]

/cc @nodejs/fs

[LiviaMedeiros]

LGTM with a suggestion.

[nathanael-ruf]

Looks like existsSync (and therefore access) returns false on an invalid symlink (see my last commit). Is this also a bug or intended behaviour?

[LiviaMedeiros]

Looks like existsSync (and therefore access) returns false on an invalid symlink (see my last commit). Is this also a bug or intended behaviour?

I think this is intended. In general, symlinks are supposed to be transparent, so accessing invalid symlink should be equal to accessing its destination (e.g. nonexistent file).

Testing if broken symlink still exists can be performed explicitly with lstat instead.
Alternatively, improvements to access (like optional argument { verbatimSymlinks: false }) might also be considered.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/48002/

[nodejs-github-bot]

Landed in 6f9175d

[LiviaMedeiros]

Thanks for the contribution!