René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"readdir(p, { withFileTypes: true }) seemingly returns wrong type","articleBody":"\u003c!--\r\nThank you for reporting a possible bug in Node.js.\r\n\r\nPlease fill in as much of the template below as you can.\r\n\r\nVersion: output of `node -v`\r\nPlatform: output of `uname -a` (UNIX), or version and 32 or 64-bit (Windows)\r\nSubsystem: if known, please specify the affected core module name\r\n\r\nIf possible, please provide code that demonstrates the problem, keeping it as\r\nsimple and free of external dependencies as you can.\r\n-->\r\n\r\n* **Version**: v13.1.0\r\n* **Platform**: Darwin White-Star.local 18.7.0 Darwin Kernel Version 18.7.0: Sat Oct 12 00:02:19 PDT 2019; root:xnu-4903.278.12~1/RELEASE_X86_64 x86_64\r\n* **Subsystem**: fs\r\n\r\n\u003c!-- Please provide more details below this comment. -->\r\n\r\nWhen listing a directory with `readdir` and `withFileTypes`, at least the promisified version of `fs.readdir` returns the wrong type for entities that are symbolic links to directories:\r\n\r\n```javascript\r\nconst { basename, join } = require('path');\r\nconst { readdir, lstat, stat, symlink, unlink } = require('fs').promises;\r\nconst LINK_NAME = basename(__filename) + '-link';\r\nconst LINK_PATH = join(__dirname, LINK_NAME);\r\n\r\nconst inspectEntity = (label, entity) => {\r\n  console.log(label, (entity.isDirectory() ? 'dir' : '') +\r\n    (entity.isFile() ? 'file' : '') +\r\n    (entity.isSymbolicLink() ? 'symlink' : ''));\r\n};\r\n\r\n(async function main() {\r\n  try {\r\n    await symlink(__dirname, LINK_PATH, 'dir');\r\n\r\n    for (const entity of await readdir(__dirname, { withFileTypes: true })) {\r\n      if (entity.name === LINK_NAME) inspectEntity('readdir', entity);\r\n    }\r\n    inspectEntity('lstat', await lstat(LINK_PATH));\r\n    inspectEntity('stat', await stat(LINK_PATH));\r\n\r\n    await unlink(LINK_PATH);\r\n  } catch (x) {\r\n    console.error(x.stack);\r\n  }\r\n})();\r\n```\r\n\r\nRunning the above script yields the following on my machine:\r\n```\r\nreaddir file\r\nlstat symlink\r\nstat dir\r\n```\r\n\r\nSince the file system entity in question is a symbolic link to a directory, I would expect the code to either report a symlink or a directory, depending on whether the implementation of `readdir` uses `stat` or `lstat` under the covers. But in *neither* case would I expect a file to be reported. Yet that's exactly what's happening on my machine. Am I missing something or is this a genuine bug?\r\n\r\nAdditional testing with a second machine suggests that this may be related to **remote file system** usage. When running the test locally on a local disk, `readdir` reports a symlink (yay!). That stands in contrast to my original testing was performed on a remotely mounted file system.\r\n\r\nAs an aside, after reading a number of old issues before filing this issue, I am guessing that `readdir` uses `stat` not `lstat` under the covers. It would seem more consistent with the rest of the API. Yet the documentation has no disclaimer on `dirent.isSymbolicLink()` as it has on `stats.isSymbolicLink()`. Either way, being more upfront about `readdir`'s behavior `{withFileTypes: true}` would go a long way towards a better developer experience. I'm happy to submit a PR for that—once I understand what's going on above.\r\n\r\nEven with better documentation though, some developers will be disappointed when whatever `readdir` uses does not meet their use case. So I am also wondering whether configurability of `stat`/`lstat` for `readdir` `withFileTypes: true` would be desirable in the long term. If that suggestion falls under the heading \"long-term costs of exposing things from core,\" I apologize. I'm gonna practice writing code *without* using `withFileTypes` for certain tonight. 😜","author":{"url":"https://github.com/apparebit","@type":"Person","name":"apparebit"},"datePublished":"2019-11-25T23:41:35Z","url":"https://github.com/nodejs/node/issues/30646"}