Stat functions throw EPERM for read-only / immutable files on Windows

See the following issue for more information: https://github.com/nodejs/node/issues/35853

Node.js throws EPERM: operation not permitted, lstat for read-only / immutable files:

Windows 10:

> icacls E:\test.txt /deny "*S-1-1-0:(F)"
> node
> fs.lstatSync('E:\\test.txt')
Uncaught Error: EPERM: operation not permitted, lstat 'E:/test.txt'
    at Object.lstatSync (fs.js:1033:3) {
  errno: -4048,
  syscall: 'lstat',
  code: 'EPERM',
  path: 'E:/test.txt'
}

Windows Explorer and most low level languages (e.g. C++, C#) can read stats of such files without problems.

Can this be fixed on the Libuv end?

• Version: All
• Platform: Windows

Maybe, pull requests welcome. The relevant code is here:

https://github.com/libuv/libuv/blob/04289fa326b790c1a4abb236d1f9d913bacfc8c6/src/win/fs.c#L1852-L1880

@bnoordhuis thanks for the reply. I don't know C, so I wouldn't be able to do it properly myself.

If anyone else wants to attempt this, since it's Windows-only issue, you can try using Windows built-in kernel32.dll functions like getfileattributesexa or filesystem lib to get file info like attributes, size, dates, etc.

The reason why it works on other languages is because they have a fallback for ERROR_ACCESS_DENIED Windows error code to gather less information (without opening a handle), libuv doesn't.

I went ahead and opened a pull request: https://github.com/libuv/libuv/pull/3268

Let me know what you guys think!

@oluan dude, you are the best. Thank you!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

PR still open, bump

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

issue nodejs/node#35853 is still active so I think this one should also

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

PR still open, bump

out of curiosity, why is the pr to fix this still open? are there some issues that make it dangerous not to gracefully handle things? this would help a lot of windows users of neo-tree.nvim

Sounds like a neo-tree bug, failing to handle an expected error case for lstat on any platform. Unless you are going to fault the kernel also for having a security model that doesn't allow arbitrary users to gain root access.