win: work around sharepoint scandir bug

[bnoordhuis]

It has been reported that for SharePoint connections mapped as a drive,
uv_fs_scandir() returns "." and ".." entries when the expectation is
that they should be filtered out.

After some investigation it looks like the driver returns ".\0" and
"..\0" for those entries, that is, it includes the zero byte in the
filename length. Rewrite the filter to catch those entries as well.

Fixes: nodejs/node#4002

R=@piscisaureus

Maybe a better fix is:

if (wchar_len > 0 && info->FileName[wchar_len - 1] == L'\0'))
  wchar_len -= 1;

Thoughts?

CI: https://ci.nodejs.org/job/libuv+any-pr+multi/195/

[saghul]

LGTM. I like your proposal of skipping the null byte like that, though I wonder if windows doesn't do any other esoteric things under some planetary alignments.

[bnoordhuis]

That was my thinking as well. I'd like to hear @piscisaureus's opinion.

[saghul]

Looks like this fell through the cracks :-S Maybe we should land this, Ben?

[bnoordhuis]

Let's try pinging @piscisaureus one more time.

[saghul]

Ping :-)

[cjihrig]

Maybe @orangemocha could weigh in? Otherwise, LGTM.

[orangemocha]

I think the change works as it is, so LGTM. Though I also would prefer the alternative version, of eating up spurious '\0' chars at the end, it's a bit cleaner and it also avoids allocating the extra wchar later on.

If you decide to go that route, consider replacing the if with a while for added robustness, as in:

while (wchar_len > 0 && info->FileName[wchar_len - 1] == L'\0'))
  wchar_len -= 1;

[bnoordhuis]

Updated to use a simple while loop, PTAL. CI: https://ci.nodejs.org/job/libuv-test-commit/33/

[saghul]

LGTM

[orangemocha]

LGTM