Use NtCreateFile on Windows
#226
Comments
|
Use |
|
My current thinking on this has changed since that PR. At the time using any Btw, the Calling Internal APIs page, while scary, is somewhat outdated. There now exists an |
|
Oh wow, I wasn't previously aware that windows-sys has bindings for |
|
Also, cap-std needs the ability to create files, so it appears we do need One thing we'll need to figure out is how to map from security QoS flags to |
|
It shouldn't be too difficult. ImpersonationLevel = (qos_flags >> 16) & 0b11;
ContextTrackingMode = (qos_flags & SECURITY_CONTEXT_TRACKING) != 0
EffectiveOnly = (qos_flags & SECURITY_EFFECTIVE_ONLY) != 0 |
Windows' `NtCreateFile` has an ability to take a directory and a relative path, so use that to implement `open_unchecked` instead of using path concatenation. We still use concatenation for other functions, but this is the first step to rewriting those to avoid it. Fixes #226.
Windows' `NtCreateFile` has an ability to take a directory and a relative path, so use that to implement `open_unchecked` instead of using path concatenation. We still use concatenation for other functions, but this is the first step to rewriting those to avoid it. Fixes #226.
Windows' `NtCreateFile` has an ability to take a directory and a relative path, so use that to implement `open_unchecked` instead of using path concatenation. We still use concatenation for other functions, but this is the first step to rewriting those to avoid it. Fixes #226.
Windows' `NtCreateFile` has an ability to take a directory and a relative path, so use that to implement `open_unchecked` instead of using path concatenation. We still use concatenation for other functions, but this is the first step to rewriting those to avoid it. Fixes #226.
Windows' `NtCreateFile` has an ability to take a directory and a relative path, so use that to implement `open_unchecked` instead of using path concatenation. We still use concatenation for other functions, but this is the first step to rewriting those to avoid it. Fixes #226.
Following changes introduced by bytecodealliance/cap-std#226
As @kubkon observed,
NtOpenFileprovides a more efficient and likely more reliable way to implementopenat-like behavior on Windows. As an example, Rust is now using it this way in itsremove_dir_allimplementation.Microsoft officially documents
NtOpenFileas an Internal API which may change between releases or even service packs of Windows, however this particular function,NtOpenFile, has apparently been stable for a long time, and since Rust itself is now depending on it, it would seem to be sufficiently stable for cap-std to use as well.The text was updated successfully, but these errors were encountered: