Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Behavior of realpath with an empty string argument #53635

Open
RedYetiDev opened this issue Jun 28, 2024 · 2 comments
Open

Behavior of realpath with an empty string argument #53635

RedYetiDev opened this issue Jun 28, 2024 · 2 comments
Labels
discuss Issues opened for discussions and feedbacks. fs Issues and PRs related to the fs subsystem / file system.

Comments

@RedYetiDev
Copy link
Member

RedYetiDev commented Jun 28, 2024

Refs: #35403

Currently, the project has 2 outcomes for different realpath functions with empty string arguments:

fs.realpathSync('') // Returns CWD
await util.promisify(fs.realpath)('') // Returns CWD

await fs.promises.realpath('') // ENOENT Error
fs.realpathSync.native('') // ENOENT Error
await util.promisify(fs.realpath.native)('') // ENOENT Error

IMO, this should be standardized to
(A) Always throw
(B) Always return CWD
(C) Return CWD for non-.native calls, throw otherwise

@RedYetiDev RedYetiDev added fs Issues and PRs related to the fs subsystem / file system. discuss Issues opened for discussions and feedbacks. labels Jun 28, 2024
@richardlau
Copy link
Member

There is always going to be a discrepency between fs.realpath() and fs.promises.realpath().

For some history fs.realpath() and fs.realpathSync() differ from native realpath and have behaviour oddities that were too breaking to change. At one point it was changed to call the native realpath but there were a number of issues that resulted in the implementation being reverted, see #7726.

When fs.promises.realpath() was added the decision was made to call the native realpath since it was a new API and be consistent with fs.realpath.native().

@RedYetiDev
Copy link
Member Author

I'm aware that there historically have been discrepency, but I think that the discrepencies (for errors) should be handled, or noted in the docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Issues opened for discussions and feedbacks. fs Issues and PRs related to the fs subsystem / file system.
Projects
None yet
Development

No branches or pull requests

2 participants