readdirSync of drive letter lists items of cwd

[cosmo0]

• Version: v6.9.1
• Platform: Windows 8.1 x64

ReaddirSync behavior depends on the current working directory (cwd/pwd) if we pass a drive letter with or without a trailing "".

It's very easy to reproduce. Here, I am on "d:" drive, and I have a "d:\Temp" folder, containing "A" and "B" sub-folders.

D:\Temp>  gci | % { $_.Name }
A
B

D:\Temp> node
> var fs = require('fs');
undefined
> fs.readdirSync('d:')
[ 'A', 'B' ]
> fs.readdirSync('d:\\')
[ '$RECYCLE.BIN',
  'Cache',
  'DEV',
  'Installers',
  'log',
  'pagefile.sys',
  'System Volume Information',
  'Temp',
  'VM' ]
> .exit
D:\Temp>

It's a very suprising behavior, and more importantly, it's not documented if expected.

[vsemozhetbyt]

Can reproduce on Win 7 x64 with Node.js 7 with additional observation: fs.readdirSync('d:') != fs.readdirSync('d:\\') only if d: is a current disk and cwd != d:\.

However, if d: is a current disk, fs.readdirSync('c:') still = fs.readdirSync('c:\\').

[cosmo0]

Yep, forgot to mention that it's only when doing readdirSync on the "current" disk (the one on which node has been launched).

I haven't tested, but I assume the problem also exists with readdir.

[vsemozhetbyt]

[vsemozhetbyt]

I haven't tested, but I assume the problem also exists with readdir.

Yep.

[vsemozhetbyt]

It seems that dir command has the same quirk: if the drive letter is not followed by a path (\ at least), the cwd content is displayed.

J:\temp>dir . /b
-arch
-mus
-v
Lv

J:\temp>dir j: /b
-arch
-mus
-v
Lv

J:\temp>dir j:\ /b
DAT
temp

I can't find this in the dir documentation, maybe this is documented in some other place.

[cosmo0]

Oh, it makes sense then. The dir and cd commands behave weirdly with multiple drives (like the cd on another drive that doesn't change the drive letter).

I would say that it's still a surprising behavior, and thus should be fixed.

[vsemozhetbyt]

Maybe the \ path should be added to a bare letter path argument in the beginning of the both functions before the binding.readdir call, if we want consistent with POSIX behavior. Or the quirk could be documented.

[addaleax]

So, I’m not a frequent Windows user, but from the little experience I have with drive-specific working dirs, it seems like Node is behaving as expected? Maybe this should just be mentioned in the docs?

[vsemozhetbyt]

I am not sure users expect from Node fs functions the same quirks as from the shell with the old DOS roots. Maybe I am wrong.

[addaleax]

If I’m reading this issue correctly, there’s nothing shell-specific about this, which is kind of why Node is having this behaviour? I mean, yes, drive-specific wds are not very intuitive when first encountering them, but at least they are consistent…

Also, two questions:

• If somebody relies on/wants the current behaviour of fs.readdir('d:'), how would they replicate that when d: is translated to d:\?
• If this is about cross-platform consistency, would libuv be the right place to raise this?

[vsemozhetbyt]

It seems you are right. So maybe this just could be added to fs documentation. However, it is unclear for me how wide the impact is and how many fs methods could be affected.

[cosmo0]

I agree with @vsemozhetbyt .
The current behavior may be consistent with how batch work, but I'm pretty sure most developers these days are not familiar with the horrors that lurk in batch scripts.
Keeping a weirdness that will trip people up just to be consistent with a 30 years old tech seems... wrong to me.

I would also argue, more importantly, that it's dependent on the drive you were on when starting node. So the behavior will not be the same for everyone.
For instance, if I distribute my app through NW.js (which I will) or Electron, depending on the drive the app is installed on, it may or may not work.
You might also have multiple servers with multiple configurations (it's not a good idea, but we're talking bad-ideas-that-should-work here), and your web site will work on one and not the other.

[S-YOU]

I believe it is not specific to particular command, but windows built-in behavior since ever.

if you just type d: in command prompt its change the drive and keep last cwd in that drive.
You can copy files across drives without specifying path, if you know you were in that folder.