Space in network share name(UNC path) causes unknown error

[MadLittleMods]

A network-share/UNC path with a space in the name throws Error: UNKNOWN: unknown error, lstat [...] when trying to run a node script node "\\ERIC-MACBOOK\Macintosh HD\foo.js".

I ran into this situation after setting up file sharing on OSX and trying to run commands on the Macintosh HD share.

Using a network share that doesn't have a space in the name works just fine; Tested with share that points to user directory on the OSX machine and a separate NAS. It doesn't seem to matter if there are spaces in the rest of the path, just the share name.

Summary

• node "\\ERIC-MACBOOK\Macintosh HD\foo.js": Throws Error: UNKNOWN: unknown error, lstat [...]
• node "\\ERIC-MACBOOK\eric\foo.js": Works normally
• node "\\some-nas\mlm\foo.js": Works normally

Terminal/CLI output

Running on Windows 10.

>node -v
v5.5.0

// foo.js
console.log('foo');

On Windows, the pushd command will map a UNC path to a temporary drive letter. Just wanted to see if it made a difference because it eliminates the space in the path used. But is probably just a pointer to the UNC path with space anyway and why it causes similar errors.

\\ERIC-MACBOOK\Macintosh HD\

C:\Users\MLM\some-folder>node "\\ERIC-MACBOOK\Macintosh HD\Users\eric\Documents\some-project\foo.js"
fs.js:887
  return binding.lstat(pathModule._makeLong(path));
                 ^

Error: UNKNOWN: unknown error, lstat '\\ERIC-MACBOOK\Macintosh HD\'
    at Error (native)
    at Object.fs.lstatSync (fs.js:887:18)
    at start (fs.js:1495:10)
    at Object.realpathSync (fs.js:1483:3)
    at toRealPath (module.js:126:13)
    at Function.Module._findPath (module.js:165:20)
    at Function.Module._resolveFilename (module.js:337:25)
    at Function.Module._load (module.js:290:25)
    at Function.Module.runMain (module.js:447:10)
    at startup (node.js:139:18)

C:\Users\MLM\some-folder>pushd "\\ERIC-MACBOOK\Macintosh HD\Users\eric\Documents\some-project"

Z:\Users\eric\Documents\some-project>node foo.js
fs.js:887
  return binding.lstat(pathModule._makeLong(path));
                 ^

Error: UNKNOWN: unknown error, lstat 'Z:\'
    at Error (native)
    at Object.fs.lstatSync (fs.js:887:18)
    at start (fs.js:1495:10)
    at Object.realpathSync (fs.js:1483:3)
    at toRealPath (module.js:126:13)
    at Function.Module._findPath (module.js:165:20)
    at Function.Module._resolveFilename (module.js:337:25)
    at Function.Module._load (module.js:290:25)
    at Function.Module.runMain (module.js:447:10)
    at startup (node.js:139:18)

Z:\Users\eric\Documents\some-project>popd

C:\Users\MLM\some-folder>

\\ERIC-MACBOOK\eric\

C:\Users\MLM\some-folder>node "\\ERIC-MACBOOK\eric\Documents\some-project\foo.js"
foo

C:\Users\MLM\some-folder>pushd "\\ERIC-MACBOOK\eric\Documents\some-project"

Z:\Documents\some-project>node foo.js
foo

Z:\Documents\some-project>popd

C:\Users\MLM\some-folder>

---

Related issues:

• [0.8.0] i can't use \\fileserver\xx.js to run node file node-v0.x-archive#3542
• v0.8.0 on Windows cannot run applications from a UNC share node-v0.x-archive#3578

[jasnell]

@orangemocha ... any ideas?

[orangemocha]

I tried locally on a Windows 2008 R2 machine with a share from the same, and I can't reproduce the issue with Node v5.5.0 nor with the current master. @MadLittleMods could you try a similar test? I suspect this might be specific to networks shares from OSX machines.

[MadLittleMods]

@orangemocha theory of OSX shares not playing nice with Windows seems plausible given the results below.

---

Local file shares (same machine) on Windows 10 with node@5.5.0 or node@5.9.0 work correctly:

> node "\\MLM-DESKTOP-PC\file share with spaces1\foo.js"
foo

> node "\\MLM-DESKTOP-PC\file-share-test1\foo.js"
foo

Accessing those Windows 10 machine shares on another Windows 8.1 with node@4.1.2 or node@5.9.0 machine work correctly:

> node "\\MLM-DESKTOP-PC\file share with spaces1\foo.js"
foo

> node "\\MLM-DESKTOP-PC\file-share-test1\foo.js"
foo

Accessing Windows 8.1 machine shares on Windows 10 machine with node@5.9.0 work correctly:

> node "\\MLM-PC\file share with spaces2\foo.js"
foo

> node "\\MLM-PC\file-share-test2\foo.js"
foo

[orangemocha]

Indeed it sounds plausible. Thanks for verifying, @MadLittleMods !

I don't have an OSX machine with me so I can't test this. I'll add it to our queue of things to investigate. If someone else wants to dive a bit deeper, I would suggest setting a breakpoint and stepping in through the stat implementation in libuv (

node/deps/uv/src/win/fs.c

Lines 1160 to 1199 in 2c67289

	INLINE static void fs__stat_impl(uv_fs_t* req, int do_lstat) {
	HANDLE handle;
	DWORD flags;
	flags = FILE_FLAG_BACKUP_SEMANTICS;
	if (do_lstat) {
	flags |= FILE_FLAG_OPEN_REPARSE_POINT;
	}
	handle = CreateFileW(req->file.pathw,
	FILE_READ_ATTRIBUTES,
	FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
	NULL,
	OPEN_EXISTING,
	flags,
	NULL);
	if (handle == INVALID_HANDLE_VALUE) {
	SET_REQ_WIN32_ERROR(req, GetLastError());
	return;
	}
	if (fs__stat_handle(handle, &req->statbuf) != 0) {
	DWORD error = GetLastError();
	if (do_lstat && error == ERROR_SYMLINK_NOT_SUPPORTED) {
	/* We opened a reparse point but it was not a symlink. Try again. */
	fs__stat_impl(req, 0);
	} else {
	/* Stat failed. */
	SET_REQ_WIN32_ERROR(req, GetLastError());
	}
	CloseHandle(handle);
	return;
	}
	req->ptr = &req->statbuf;
	req->result = 0;
	CloseHandle(handle);
	}

) and to find out what error is being returned. Once we know the error code, a web search should reveal if it's a known issue with OSX and SMB, and if there are any known solutions.

[upq]

+1
Using windows 10 and osx 10.11.4

[jasongin]

I am able to reproduce the error. But interestingly, the error does not occur for any normal shared folder, whether or not it has a space in the name. The only way I can reproduce the error is with a Macintosh HD share. There must be something different about how the Macintosh HD is shared over SMB. I'll try to debug as @orangemocha suggested above.

[jasongin]

Submitted PR libuv/libuv#996

[saghul]

The libuv PR landed. I'm reopening the issue until we upgrade the bundled libuv.

[MadLittleMods]

Curious how you track when the libuv dependency gets upgraded and bundled in order to know when this issue should be closed?

Does this issue need the libuv label?