fs.lstatSync doesn't handle specific Windows REPARSE POINTS

[paulbouwer]

• Version: 7.9.0
• Platform: Windows 10 (16179)
• Subsystem: fs (lstat)

Referenced issues:

• hyper #1776 - Gaze is adding all folders in HOME to watch list
• gaze #239 - fs.lstatSync doesn't handle specific Windows REPARSE POINTS

Issue

While tracking down an issue affecting hyper, it lead me to the use by gaze of fs.lstatSync.

It seems that on Windows, there is something different about the reparse point on OneDrive local sync folders, that results in a EINVAL error from fs.lstatSync. The fs.lstatSync correctly handles other junctions, folders and files in HOME with no error.

Error example - OneDrive

C:\> node
> fs.lstatSync('C:/Users/pabouwer/OneDrive')
Error: EINVAL: invalid argument, lstat 'C:\Users\pabouwer\OneDrive'
    at Object.fs.lstatSync (fs.js:961:11)
    at repl:1:4
    at ContextifyScript.Script.runInThisContext (vm.js:23:33)
    at REPLServer.defaultEval (repl.js:339:29)
    at bound (domain.js:280:14)
    at REPLServer.runBound [as eval] (domain.js:293:12)
    at REPLServer.onLine (repl.js:536:10)
    at emitOne (events.js:101:20)
    at REPLServer.emit (events.js:191:7)
    at REPLServer.Interface._onLine (readline.js:241:10)

C:\> junction -nobanner "C:/Users/pabouwer/OneDrive"
C:\Users\pabouwer\OneDrive: UNKNOWN MICROSOFT REPARSE POINT

Working example - My Documents

C:\> node
> fs.lstatSync('C:/Users/pabouwer/My Documents')
Stats {
  dev: 2348871125,
  mode: 41398,
  nlink: 1,
  uid: 0,
  gid: 0,
  rdev: 0,
  blksize: undefined,
  ino: 8444249301777451,
  size: 27,
  blocks: undefined,
  atime: 2017-04-23T23:24:58.150Z,
  mtime: 2017-04-23T23:24:58.150Z,
  ctime: 2017-04-23T23:24:58.185Z,
  birthtime: 2017-04-23T23:24:58.150Z }

C:\> junction -nobanner "C:/Users/pabouwer/My Documents"
C:\Users\pabouwer\My Documents: JUNCTION
   Print Name     : C:\Users\pabouwer\Documents
   Substitute Name: C:\Users\pabouwer\Documents

[Trott]

@nodejs/platform-windows @nodejs/fs

[refack]

So windows likes to create these "Broken" junctions all over the place that have the equivalent of chmod 000, and I think they are only used internally for WIN32 to resolve the actual folder they link to. You can't navigate into them even native windows tools bork when interacting with them as @paulbouwer demonstrated

C:\> junction -nobanner "C:/Users/pabouwer/OneDrive"
C:\Users\pabouwer\OneDrive: UNKNOWN MICROSOFT REPARSE POINT

Does anyone think we should handle them in a special manner?

P.S. Just the first answer I found in Google https://goo.gl/Daj2vu (the jist: don't mess with them)

P.P.S Every user home has these and none of them work.

 <JUNCTION>     Application Data [C:\Users\refael\AppData\Roaming]
 <JUNCTION>     Cookies [C:\Users\refael\AppData\Roaming\Microsoft\Windows\Cookies]
 <JUNCTION>     Local Settings [C:\Users\refael\AppData\Local]
 <JUNCTION>     My Documents [C:\Users\refael\Documents]
 <JUNCTION>     NetHood [C:\Users\refael\AppData\Roaming\Microsoft\Windows\Network Shortcuts]
 <JUNCTION>     PrintHood [C:\Users\refael\AppData\Roaming\Microsoft\Windows\Printer Shortcuts]
 <JUNCTION>     Recent [C:\Users\refael\AppData\Roaming\Microsoft\Windows\Recent]
 <JUNCTION>     SendTo [C:\Users\refael\AppData\Roaming\Microsoft\Windows\SendTo]
 <JUNCTION>     Start Menu [C:\Users\refael\AppData\Roaming\Microsoft\Windows\Start Menu]
 <JUNCTION>     Templates [C:\Users\refael\AppData\Roaming\Microsoft\Windows\Templates]

[bzoz]

Sorry, I can't reproduce this. I've tried different machines, a fresh Win10 install, with OneDrive uninstalled, etc. Each time lstatSync returned without error.

[refack]

Sorry, I can't reproduce this. I've tried different machines, a fresh Win10 install, with OneDrive uninstalled, etc. Each time lstatSync returned without error.

Someone is behaving better either the OS or libuv.

[bzoz]

@paulbouwer can you provide some more info about your setup?

[refack]

I was reading today about "OneDrive Files On-Demand", maybe that is the case, I'll try repro.

[UsmanMohammad]

Having the same issue, I am using insider build 16215 and have OneDrive Files On-Demand enabled

[refack]

@UsmanMohammad thank you for the info.

[paulbouwer]

@bzoz - I have this issue on Windows 10 that is pre the OneDrive Files On-Demand feature. I'll check what other additional info I can find.

[cerebrate]

@paulbouwer Unfortunately, there're quite a lot of Windows features build on reparse points and have been since W2K, any of which can cause this error - mounting a volume on a folder, remote storage, distributed file system, junction points/symbolic links (which I believe lstat understands as equivalent to Unix-style symlinks, or at least it doesn't fail on them), single-instance storage, and that's not even counting the non-Microsoft stuff. Any of those other than junction points, I believe, will produce the same lstat()/lstatSync() error.

(Edited for thinko.)