fix: reject empty paths to prevent accidental cwd deletion - #342

How is rimraf to know that this is accidental cwd removal, and not intentional cwd removal?

I suppose it's fair to just mimic what Node does, which we can do by just not resolving the paths in the first place before passing them to the implementation. However, "mimic what node does" gets tricky when looking at the other implementations.

For example:

• fs.rmSync('.', { recursive: true, force: true }) Raises an error, but only after deleting the contents of the cwd (strange code, -4094, syscall: 'rm').
• fs.rmSync('', { recursive: true }) Raises an error immediately (lstat('') ENOENT failure). If force: true is provided, then it silently does nothing.
• fs.rmSync(process.cwd(), { recursive: true, force: true }) Raises no error, deletes the CWD.
• fs.rmSync('a/.', { recursive: true, force: true }) raises that same -4094 error, but with the invalid path as a/.
• fs.rmSync('a/b/../.', { recursive: true, force: true }) raises no error, deletes a contents, but not a itself, even though a/b/../. resolves to a (!?)
• fs.rmSync('a/../.', { recursive: true, force: true }) Removes a and its contents, even though a/../. resolves to the cwd (!?)

Deleting whitespace-only paths must continue to be supported, how else would you delete a file named ' ' or '\t'? (Both of these are valid path names on Windows and Unix systems!)

So, I think there's some fixing to be done here, but this PR goes too far. I'll take a look in the coming days. In all cases, rimraf should either mimic Node's behavior, or we should send a PR to node to fix fs.rm if it's incorrect.

Thank you for the detailed analysis! You're absolutely right that:

1. Whitespace-only paths like ' ' or '\t' are valid filenames and must be supported
2. The behavior should match Node's fs.rm (or Node should be fixed if incorrect)
3. The edge cases you found with . and .. resolution are interesting inconsistencies

I'll leave this for you to handle since you have the full context on what rimraf's behavior should be. Happy to help if you'd like me to work on a revised approach after you've had a chance to investigate.

Thanks for the detailed feedback @isaacs! You're absolutely right - whitespace paths are valid filenames.

I've updated the PR to:

• Only reject empty string '' - prevents the resolve('') → cwd catastrophe
• Allow whitespace paths like ' ' and '\t' - these are valid filenames that users should be able to delete
• Updated tests to verify whitespace paths resolve correctly instead of throwing

The behavior now matches Node's approach more closely - only the literal empty string gets special handling.

Once nodejs/node#61958 is fixed, I'll update rimraf to behave accordingly in all implementations.

Thanks for filing the upstream issue. Since you'll be updating rimraf after nodejs/node#61958 is resolved, should I close this PR? Happy to do so if it's just adding noise.

Yeah, I'm going to put up a PR to mirror the node behavior, and we can land it once that is finalized in Node, just to be sure it's the right approach.

Thanks for bringing this up :)