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

MadLittleMods · 2016-02-09T17:32:03Z

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:

The text was updated successfully, but these errors were encountered:

jasnell · 2016-03-22T19:23:06Z

@orangemocha ... any ideas?

orangemocha · 2016-03-22T19:44:05Z

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 · 2016-03-22T21:09:00Z

@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 · 2016-03-22T23:02:49Z

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 · 2016-06-13T12:12:15Z

+1
Using windows 10 and osx 10.11.4

jasongin · 2016-08-13T00:28:22Z

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 · 2016-08-15T18:51:32Z

Submitted PR libuv/libuv#996

saghul · 2016-08-16T09:04:59Z

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

MadLittleMods · 2016-08-16T09:09:10Z

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?

saghul · 2016-08-16T09:27:02Z

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!

Fixes: libuv#995 Fixes: nodejs/node#5160 PR-URL: libuv#996 Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>

MadLittleMods · 2016-10-27T05:21:58Z

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

cjihrig · 2016-10-27T13:56:28Z

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.

BridgeAR · 2017-05-30T19:29:56Z

This is outdated and can be closed.

wadetb · 2017-09-01T16:34:05Z

@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!

mscdex added module Issues and PRs related to the module subsystem. windows Issues and PRs related to the Windows platform. labels Feb 9, 2016

MadLittleMods mentioned this issue Feb 10, 2016

Desktop v3 gitterHQ/desktop#100

Merged

jasongin mentioned this issue Aug 15, 2016

lstat on Windows fails for "Macintosh HD" network share libuv/libuv#995

Closed

saghul closed this as completed in libuv/libuv@7ae4b1a Aug 16, 2016

saghul reopened this Aug 16, 2016

saghul added the libuv Issues and PRs related to the libuv dependency or the uv binding. label Aug 16, 2016

saghul pushed a commit to saghul/libuv that referenced this issue Aug 18, 2016

win: fix lstat reparse point without link data

c9c9d52

Fixes: libuv#995 Fixes: nodejs/node#5160 PR-URL: libuv#996 Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>

Ben3eeE mentioned this issue Nov 14, 2016

UNC paths are not supported. Defaulting to Windows directory. atom/atom#12478

Closed

6 tasks

gibfahn closed this as completed May 30, 2017

This was referenced Apr 28, 2023

[Snyk] Fix for 114 vulnerabilities aliscco/alisco-node#338

Open

[Snyk] Fix for 4 vulnerabilities aliscco/alisco-node#349

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

MadLittleMods commented Feb 9, 2016

jasnell commented Mar 22, 2016

orangemocha commented Mar 22, 2016

MadLittleMods commented Mar 22, 2016

orangemocha commented Mar 22, 2016

upq commented Jun 13, 2016

jasongin commented Aug 13, 2016

jasongin commented Aug 15, 2016

saghul commented Aug 16, 2016

MadLittleMods commented Aug 16, 2016

saghul commented Aug 16, 2016

MadLittleMods commented Oct 27, 2016

cjihrig commented Oct 27, 2016

BridgeAR commented May 30, 2017

wadetb commented Sep 1, 2017

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

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

Comments

MadLittleMods commented Feb 9, 2016

Summary

Terminal/CLI output

\\ERIC-MACBOOK\Macintosh HD\

\\ERIC-MACBOOK\eric\

jasnell commented Mar 22, 2016

orangemocha commented Mar 22, 2016

MadLittleMods commented Mar 22, 2016

orangemocha commented Mar 22, 2016

upq commented Jun 13, 2016

jasongin commented Aug 13, 2016

jasongin commented Aug 15, 2016

saghul commented Aug 16, 2016

MadLittleMods commented Aug 16, 2016

saghul commented Aug 16, 2016

MadLittleMods commented Oct 27, 2016

cjihrig commented Oct 27, 2016

BridgeAR commented May 30, 2017

wadetb commented Sep 1, 2017

`\\ERIC-MACBOOK\Macintosh HD\`

`\\ERIC-MACBOOK\eric\`