Skip to content

Inconsistent fs.rm behavior with "force" option on Windows vs mac/linux #45253

Closed
Closed
Inconsistent fs.rm behavior with "force" option on Windows vs mac/linux#45253
Labels
fsIssues and PRs related to file-system APIs and the fs module.help wantedIssues that need assistance from volunteers or PRs that need help to proceed.windowsIssues and PRs related to the Windows platform.

Description

@VincentBailly
VincentBailly
opened on Oct 31, 2022

Version

16.17.0

Platform

Linux my-VM 5.15.0-1022-azure #27~20.04.1-Ubuntu SMP Mon Oct 17 02:03:50 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

node:fs

What steps will reproduce the bug?

touch foo
node -e 'require("fs").promises.rm("foo/bar", { force: true })'

How often does it reproduce? Is there a required condition?

No condition, it reproduces on mac and on Linux.

What is the expected behavior?

Same behavior as on Windows, the function call succeeds and no exception is thrown.

What do you see instead?

Unhandled exception

node:internal/process/promises:279
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: ENOTDIR: not a directory, stat 'foo/bar'] {
  errno: -20,
  code: 'ENOTDIR',
  syscall: 'stat',
  path: 'foo/bar'
}

Additional information

No response

Activity

  1. VincentBailly
    changed the title [-]Inconsistent fs.rm and fs.stat behavior on Windows vs mac/linux[/-] [+]Inconsistent fs.rm behavior on Windows vs mac/linux[/+] on Oct 31, 2022
  2. VoltrexKeyva
    added
    fsIssues and PRs related to file-system APIs and the fs module.
    on Oct 31, 2022

  3. dnalborczyk commented on Oct 31, 2022

    @dnalborczyk
    dnalborczyk
    on Oct 31, 2022
    Contributor

    only tested this on a mac, but the behavior described above should be correct, as the path foo/bar does not exist. if this works on windows, I would think that it would need to be fixed for that platform, not the other way around.

    @VincentBailly are you sure you used the same paths on windows and linux?

  4. VincentBailly
    changed the title [-]Inconsistent fs.rm behavior on Windows vs mac/linux[/-] [+]Inconsistent fs.rm behavior with "force" option on Windows vs mac/linux[/+] on Nov 1, 2022

  5. VincentBailly commented on Nov 1, 2022

    @VincentBailly
    VincentBailly
    on Nov 1, 2022
    Author

    @dnalborczyk thank you for the response. The issue was not explicit enough, sorry. Let me clarify.

    The issue has to do with the option "force", the documentation says that the "force" option makes the function ignore exceptions when the path does not exist.

    https://nodejs.org/docs/latest-v16.x/api/fs.html#fspromisesrmpath-options

  6. aduh95 commented on Nov 1, 2022

    @aduh95
    aduh95
    on Nov 1, 2022
    Contributor

    On macOS:

    $ touch foo
$ rm -f foo/bar
rm: foo/bar: Not a directory
$ node -e 'fs.promises.rm("foo/bar", {force:true})'
node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: ENOTDIR: not a directory, stat 'foo/bar'] {
  errno: -20,
  code: 'ENOTDIR',
  syscall: 'stat',
  path: 'foo/bar'
}

Node.js v20.0.0-pre

    It looks like the built-in method also throw in this case. I suggest we update the documentation, I think we should try keeping the behavior consistent with the built-in tool. We should probably fix the Windows behavior then, I don't have a Windows machine to work on that, so if there are any volunteers that's be awesome.

    /cc @nodejs/fs

  7. aduh95
    added
    help wantedIssues that need assistance from volunteers or PRs that need help to proceed.
    windowsIssues and PRs related to the Windows platform.
    on Nov 1, 2022

  8. LiviaMedeiros commented on Nov 1, 2022

    @LiviaMedeiros
    LiviaMedeiros
    on Nov 1, 2022
    Member

    the documentation says that the "force" option makes the function ignore exceptions when the path does not exist.

    When true, exceptions will be ignored if path does not exist.

    Maybe this part requires rewording to avoid any ambiguity, but it sounds correct to me. force flag tells to ignore ENOENT on the path (i.e. target file or any directory in it), while the error we in this example is ENOTDIR.

    We should probably fix the Windows behavior then, I don't have a Windows machine to work on that, so if there are any volunteers that's be awesome.

    I'm not sure about direct native equivalent of rm -f in Windows, but it works like this in cygwin:

    $ touch foo
$ rm foo/bar
rm: cannot remove 'foo/bar': Not a directory
$ node -e 'require("fs").promises.rm("foo/bar")'
node:internal/process/promises:288
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: ENOENT: no such file or directory, stat 'C:\foo\bar'] {
  errno: -4058,
  code: 'ENOENT',
  syscall: 'stat',
  path: 'C:\\foo\\bar'
}

$ rm -f foo/bar
[no error]
$ node -e 'require("fs").promises.rm("foo/bar", { force: true })'
[no error]

    So, behaviour with force: true is consistent. With force: false it throws ENOENT instead.

  9. VincentBailly commented on Nov 1, 2022

    @VincentBailly
    VincentBailly
    on Nov 1, 2022
    Author

    If this can help: on Linux (Ubuntu 22.04 & bash 5.0.17 & coreutils 8.30) the behavior is inconsistent between rm and nodejs

    $ rm -rf foo # cleanup to be sure
$ touch foo
$ rm foo/bar
rm: cannot remove 'foo/bar': Not a directory
$ rm -f foo/bar # no error
$ node -e 'require("fs").promises.rm("foo/bar")' # error expected, same as 'rm'
node:internal/process/promises:279
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: ENOTDIR: not a directory, stat 'foo/bar'] {
  errno: -20,
  code: 'ENOTDIR',
  syscall: 'stat',
  path: 'foo/bar'
}
$ node -e 'require("fs").promises.rm("foo/bar", { force: true })' # error non expected, 'rm' command did not error out in same situation.
node:internal/process/promises:279
            triggerUncaughtException(err, true /* fromPromise */);
            ^

[Error: ENOTDIR: not a directory, stat 'foo/bar'] {
  errno: -20,
  code: 'ENOTDIR',
  syscall: 'stat',
  path: 'foo/bar'
}

  10. VincentBailly commented on Nov 1, 2022

    @VincentBailly
    VincentBailly
    on Nov 1, 2022
    Author

    Here is a summary of what different tools do in this scenario:

    Tool behavior documentation
    core-utils (linux) no error ignore nonexistent files and arguments
    nodejs on linux error When true, exceptions will be ignored if path does not exist
    - - -
    Mac os X utilities error If the file does not exist, do not display a diagnostic message or modify the exit status to reflect an error.
    nodejs on mac error When true, exceptions will be ignored if path does not exist
    - - -
    cygwin no error ignore nonexistent files,
    git bash for windows no error ignore nonexistent files and arguments
    nodejs on windows no error When true, exceptions will be ignored if path does not exist

    The NodeJS documentation says that rm is modeled on the standard POSIX rm utility, which says "if file does not exist and -f is specified, skip this file"

  11. VincentBailly commented on Nov 1, 2022

    @VincentBailly
    VincentBailly
    on Nov 1, 2022
    Author

    Since this is tightly related to the behavior of stat, let's also consider this:

    stat tool behavior
    core-utils (linux) Not a directory
    nodejs on linux Not a directory
    - -
    macos utilities ???
    nodejs on macos ???
    - -
    cygwin ???
    git bash for Windows Not a directory
    nodejs on Windows no such file or directory

  12. VincentBailly commented on Nov 1, 2022

    @VincentBailly
    VincentBailly
    on Nov 1, 2022
    Author

    It seems that fixing the stat command on Windows will be enough to make rm consistent.

  13. aduh95 commented on Nov 1, 2022

    @aduh95
    aduh95
    on Nov 1, 2022
    Contributor

    On macOS:

    $ rm -rf foo
$ touch foo
$ stat foo/bar
stat: foo/bar: stat: Not a directory
$ node -e 'fs.statSync("foo/bar")'
node:internal/fs/utils:348
    throw err;
    ^

Error: ENOTDIR: not a directory, stat 'foo/bar'
    at Object.statSync (node:fs:1596:3)
    at [eval]:1:4
    at Script.runInThisContext (node:vm:129:12)
    at Object.runInThisContext (node:vm:313:38)
    at node:internal/process/execution:79:19
    at [eval]-wrapper:6:22
    at evalScript (node:internal/process/execution:78:60)
    at node:internal/main/eval_string:28:3 {
  errno: -20,
  syscall: 'stat',
  code: 'ENOTDIR',
  path: 'foo/bar'
}

Node.js v18.11.0

  14. Ceres6 commented on Feb 10, 2025

    @Ceres6
    Ceres6
    on Feb 10, 2025
    Contributor

    Is there any work left here?

  15. StefanStojanovic commented on May 20, 2025

    @StefanStojanovic
    StefanStojanovic
    on May 20, 2025
    Contributor

    Since the last comment was 3 months ago, and there was no answer, I'll go ahead and close this. Please reopen if needed.

  16. StefanStojanovic
    closed this as completedon May 20, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    fsIssues and PRs related to file-system APIs and the fs module.help wantedIssues that need assistance from volunteers or PRs that need help to proceed.windowsIssues and PRs related to the Windows platform.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions