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

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:

@orangemocha

@orangemocha ... any ideas?

@MadLittleMods

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.

@orangemocha

@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

@MadLittleMods

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.

+1
Using windows 10 and osx 10.11.4

@orangemocha

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.

Submitted PR libuv/libuv#996

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

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?

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

It's an artisanal process :-) Basically, when we get an issue or PR in libuv which comes from Node, we reference it in the commit message. Then, when the upgrade PR is made to Node we just git log and copy all the Fixes: links which point to Node into the PR metadata. That way the upgrade PR will close this.

It's a bit unfortunate that GitHub closes issues cross-repo if you have commit access to both, so we have to remember to re-open issues. Or we could switch to Refs:, but this is actually a fix, so...

Does this issue need the libuv label?

Yeah, added it!

win: fix lstat reparse point without link data

Just a friendly check-in. Does the bundle have an upgraded libuv now?

libuv was updated to 1.10.0 a few days ago. It's available on the master branch, but hasn't gone out in a release yet.

This is outdated and can be closed.

@jasongin

@jasongin, I encountered a similar issue with Node.js and hierarchical storage management software -
something like Microsoft GVFS.

Because my fix touches this same libuv code, I attempted to reproduce this issue to confirm that the workaround is not affected, but I cannot make uv_fs_lstat fail in the same way reported here.

First, I adapted a libuv test in test-fs.c to lstat a file on a MacBook Pro over SMB using path \\10.90.240.79\Macintosh HD\test.js. Stepping in the debugger, I found that this did not trigger your workaround: ERROR_NOT_A_REPARSE_POINT was not returned by DeviceIoControl.

I also tried testing the same version of Node.js reported in this issue using nvs run 5.5.0 "\\10.90.240.79\Macintosh HD\test.js", but that succeeded without the exception reported above.

My PC is running Windows 10 build 15063.540 and the MacBook Pro is running macOS Sierra 10.12.3.

Are you still able to reproduce the issue on recent Windows builds, and if so do you have any suggestions as to what step I might be missing? Thanks!

Navigation Menu

Repository navigation

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

Summary

Terminal/CLI output

`\\ERIC-MACBOOK\Macintosh HD\`

`\\ERIC-MACBOOK\eric\`

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	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);
	}

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

Description

Summary

Terminal/CLI output

\\ERIC-MACBOOK\Macintosh HD\

\\ERIC-MACBOOK\eric\

Activity

jasnell commented on Mar 22, 2016

orangemocha commented on Mar 22, 2016

MadLittleMods commented on Mar 22, 2016

orangemocha commented on Mar 22, 2016

upq commented on Jun 13, 2016

jasongin commented on Aug 13, 2016

jasongin commented on Aug 15, 2016

saghul commented on Aug 16, 2016

MadLittleMods commented on Aug 16, 2016

saghul commented on Aug 16, 2016

MadLittleMods commented on Oct 27, 2016

cjihrig commented on Oct 27, 2016

BridgeAR commented on May 30, 2017

wadetb commented on Sep 1, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`\\ERIC-MACBOOK\Macintosh HD\`

`\\ERIC-MACBOOK\eric\`