fs.rmdir() on file (not directory) has "ENOTDIR" on Linux/macOS vs "ENOENT" on Windows #8797
Description
- 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
Activity
silverwind commentedon Sep 27, 2016
What version of Windows? I cannot reproduce on Windows 7 (getting ENOENT, while the docs would suggest ENOTEMPTY to be thrown).
jokeyrhyme commentedon Sep 27, 2016
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 commentedon Sep 27, 2016
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 commentedon Sep 27, 2016
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.
[-]`fs.rmdir()` on file (not directory) has Error result on Linux/macOS, no Error on Windows[/-][+]`fs.rmdir()` on file (not directory) has "ENOTDIR" on Linux/macOS vs "ENOENT" on Windows[/+]jokeyrhyme commentedon Sep 28, 2016
@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 commentedon Sep 30, 2016
Do I understand correctly that the error was always there, just with a different code?
jokeyrhyme commentedon Sep 30, 2016
@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 commentedon Sep 30, 2016
@nodejs/platform-windows should we attempt to normalize error codes in this case? The issue here is that Unix has a
ENOTDIRwhile the Windows API does not know this code.Being smart about ENOENT won't work on Windows
Trott commentedon Jul 10, 2017
Re-pinging @nodejs/platform-windows. Also: @nodejs/fs.
Keep this open?
cjihrig commentedon Jul 10, 2017
I think this is something we could document.
ENOTDIRseems like the more correct error code, but normalizing that on Windows would probably not be worth it.3 remaining items
docs: add note about fs.rmdir()
docs: add note about fs.rmdir()
docs: add note about fs.rmdir()
docs: add note about fs.rmdir()
docs: add note about fs.rmdir()
docs: add note about fs.rmdir()
docs: add note about fs.rmdir()