Saúl Ibarra Corretgé

As for the ones you reported already, my 2 cents: ERROR_NOT_READY -> EAGAIN ERROR_VIRUS_INFECTED -> EIO ERROR_DEVICE_HARDWARE_ERROR -> EIO

On Windows, there actual error is available in the `uv_fs_t` structure: https://github.com/libuv/libuv/blob/2c279504f92a7ab1fc54c85ec36272722198a77e/include/uv/win.h#L611 While it's part of the "private" fields, you should be ok using it. Now, since you are using...

> If introducing a new error code in libuv is no option That hasn't been discussed. @libuv/collaborators thoughts on adding UV_EVIRUS? Obviously it wouldn't map to anything on Unix. FWIW:...

> My only concern is that embedders might need to add a bunch of checks for `UV_EVIRUS` (or other platform specific code). How do? We'd take care of the mapping,...

> I don't really fully agree with "some" or "easily fixable" here. In the immortal words of The Dude: that's just, like, your opinion, man. > There are at least...

> You post a document from when libuv was introduced but libuv was spawned from node.js which was not designed with windows in mind. > The documentation of the fs...

For context, the original issue is being addressed here: https://github.com/libuv/libuv/pull/4421

Not sure I like the approach. The others are modes, but the new one is a flag. It's also only implemented in windows and with no tests... What use case...

> My goal is to address the issue where uv_stop might be called inadvertently before the loop starts, ensuring that uv_run can still be executed correctly. The primary purpose of...

> Because connect and uv_run are not in the same thread, there is a scenario where the user calls the connect method and then immediately calls uv_stop after uv_run. Due...