fs.rmdir() on file (not directory) has "ENOTDIR" on Linux/macOS vs "ENOENT" on Windows

[jokeyrhyme]

• Version: 6.6.0
• Platform: Darwin fulmen.local 16.1.0 Darwin Kernel Version 16.1.0: Mon Sep 12 19:36:59 PDT 2016; root:xnu-3789.20.43~78/RELEASE_X86_64 x86_64
• Subsystem: "fs" module

Just noticed an inconsistency between Windows and everything else (why, Windows, why?!) for the fs.rmdir() and fs.rmdirSync() built-in functions.

const fs = require('fs')
const path = require('path')

fs.rmdirSync(__filename)

Assuming you save this to a file and node it, this file deletes itself on Windows instead of throwing an error as on Linux and macOS.

Note that fs.unlink() and fs.unlinkSync() consistently result in Errors if used on a directory's path.

Update: the snippet results in an "ENOENT" error on Windows, instead of an "ENOTDIR" error as on Linux / macOS

[silverwind]

What version of Windows? I cannot reproduce on Windows 7 (getting ENOENT, while the docs would suggest ENOTEMPTY to be thrown).

[jokeyrhyme]

Well, I was writing this library: https://github.com/jokeyrhyme/idempotent-fs.js

And the AppVeyor CI tests fail for related assertions: https://ci.appveyor.com/project/jokeyrhyme/idempotent-fs-js/build/1.0.4/job/sd2snlj4iv5ya0oi

I'll run this against versions of Windows I can control today. It's possible that it's file-system related. Maybe there's a difference between FAT32 and NTFS?

[silverwind]

Maybe there's a difference between FAT32 and NTFS?

I'd say it's unlikely. Probably more likely that the error is swallowed for files on network drivers. One thing I'd watch out while testing is to try removing a different file than the current script because there might be a active handle (resulting in EACCES).

[jokeyrhyme]

This particular test is deliberately trying to get an error, and I was lazily avoiding the need to create temporary directories. :P But yes, not a great idea generally.

[jokeyrhyme]

@silverwind yeah, after some testing on Windows 10 on an NTFS partition in VirtualBox, I can see that fs.rmdir(__filename) throws "ENOENT", which is different to the "ENOTDIR" error I was getting on Linux / macOS. There's still something fishy here, but it isn't exactly what I initially reported.

[silverwind]

Do I understand correctly that the error was always there, just with a different code?

[jokeyrhyme]

@silverwind yep. I've updated the Issue title and description. I have found that the error codes are inconsistent. We just have to determine now if this is worth fixing, or if it is minor enough to just ignore.

[silverwind]

@nodejs/platform-windows should we attempt to normalize error codes in this case? The issue here is that Unix has a ENOTDIR while the Windows API does not know this code.

[Trott]

Re-pinging @nodejs/platform-windows. Also: @nodejs/fs.

Keep this open?

[cjihrig]

I think this is something we could document. ENOTDIR seems like the more correct error code, but normalizing that on Windows would probably not be worth it.

[refack]

Note for those coming after...
This idiosyncrasy should be documented in https://github.com/nodejs/node/blob/master/doc/api/fs.md#fsrmdirpath-callback