You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is no good way to get the file type, normally you would AND with S_IFMT and test for equality with all the S_* types.
Testing the bits with Mode.test is not enough since the bits are shared between different file types.
Currently the only way I found to figure the filetype was doing:
This is indeed an awkward part of the API and will need to change. Historically, it became this way because S_IFMT was added later than the other bits. However, I see that this is no longer being used in eio_luv at the moment, so I think it can be delayed, after a maintenance release of Luv.
Thank you for looking into this.
It's not a pressing matter for us as I ended up just grabing the stat directly through the Unix module.
There's also the future of luv/libuv being phased out in EIO in favor of eio_posix + some windows backend, not due to luv, more due to how libuv associates handles with loops which make it cumbersome to support in EIO.
mode
is aMode.numeric
There is no good way to get the file type, normally you would AND with S_IFMT and test for equality with all the S_* types.
Testing the bits with
Mode.test
is not enough since the bits are shared between different file types.Currently the only way I found to figure the filetype was doing:
And then doing all the mask and comparison myself, see ocaml-multicore/eio#339
The text was updated successfully, but these errors were encountered: