Description
Overview
There are a number of problems related to the realpath change in #3594. This issue aims to serve a single entry point to those, with the hope that we have a clear picture and are able to address them one way or another.
Please: Do not report new issues here, this is a collection of the currently existing ones.
- [unix] symlink depth of > 32 gives ELOOP on some platforms (Node 6 fs.realpath behavior changes #7175)
- [win] realpath doesn't work on ramdisks (Error: EISDIR illegal operation on directory - Binding.realpath #6861)
- [win] realpath results are different when using substed drives (win, fs: fix realpath behavior on substed drives #7559)
- [win] permissions problem on mapped paths (Windows standard user cannot run any node 6 js file on mapped path #7192)
- [win] problem in Windows Docker container (npm in Node 6.2.0 MSI does not work in Windows Docker container #7044)
- [win] Node can be inconsistent in what case builtin functions use for drive letters [On Windows, Node can be inconsistent in what case builtin functions use for drive letters #6624]
- [win] Repro of Node loading modules twice on Windows [Repro of Node loading modules twice on Windows #6978]
Current state
Bad. Some of these issues have PRs addressing a specific issue, but none fix all of them.
Original reasoning
Following the issue trail I can only see performance as the argument for creating uv_fs_realpath
and using it in node:
- fs.realpath 70x slower than native node-v0.x-archive#7902
- fs.realpath 70x slower than native #2680
- fs: optimize realpath using uv_fs_realpath() #3594
Way forward(?)
After scratching my head for a while I have no other suggestion than to revert back to the JS implementation. Since we changed the API to remove the cache
argument, which was needed for performance, I suggest we keep the cache private, thus avoiding yet another API change.
I'll update the libuv documentation so nobody tries to bring this up again in Node v103.x, or at least not without validating it solves all the aforementioned problems.
Suggestions / alternatives are more than welcome, but at this point it's all or nothing, we either have a plan for fixing all the problems or we revert, IMHO.