ignore prep_openat2* for now
add non-at variant of some unlink, rename, mkdir, symlink, link
TODO: add Sync File Flags
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Add timeout update, cancel_fd, epoll_wait, files_update, open, open_direct, f/madvice
don't implement f/madvice64 for now I doubt it is used by a lot of people in practice
Implement BufferGroup read_multishot
Try to make definition of function align as logically as posible with
liburing to make keeping our implementation in sync easy
TODO: add M/Fadvice enum flags
TODO: understand buffer_selection and how its different from BufferGroup
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
add IoUring tee syscall functionality
adapt ReadBuffer union idea for read_fixed to support fixed read and readv
Use same idea and create a WriteBuffer type for write() and write_fixed()
ignored flags for splice and tee lets see if they become important in
the future
add a get_data helper to Cqe
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Future enhancement:
enter_ring_fd: u24,
init_flags: u8,
register functions that require the extra fields above like
io_uring_register_ring_fd, io_uring_close_ring_fd,
io_uring_clone_buffers_offset, io_uring_set_iowait not implemented
register_*_tag functions not implemented
remove unnecessary use of @ptrCast in io_uring_register
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
update io_uring_enter and io_uring_register syscalls to
use IoUring flags and types
Cleanup comments
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Prefer Using aliases over packed union field
Fix bug in HANDLE_FID declaration
Use EpollOp op type and Epoll packed struct flag type in IoUring
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Replace SO with So type and Add SO named constants for compatability
Replace SOL with Sol type and Add SOL named constants for compatability
Replace some more typed flags with their typed equivalent
Remove any unnecessary IoUring dependency on linux.*
Add TODOs for all untyped flags
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
4❯ zig test lib/std/std.zig --zig-lib-dir lib --test-filter "os.linux"
68/116 os.linux.test.test.futex2_wait...SKIP
69/116 os.linux.test.test.futex2_wake...SKIP
70/116 os.linux.test.test.futex2_requeue...SKIP
111/116 os.linux.IoUring.test.waitid...SKIP
116/116 os.linux.IoUring.test.bind/listen/connect...SKIP
111 passed; 5 skipped; 0 failed.
fix skipKernelLessThan fn to work on wsl linux
fix logical error in flags compatibility check
Update all IoUring to use the implemented flags
bandage types that affect posix for now so that the scope
doesn't become unmanageable
TODO: impl linux.SOL and linux.SO types
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Add Shut, PF, AF, IPPROTO types
Update IoUring and test to use some of this flags
TODO: avoid breaking API and make transitioning smooth
Instead mark the previous API as deprecated for at least
One zig release while using the new in the Zig codebase
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Add RenameFlags for IoUring renameat
Start update io_uring Types in linux.zig to use IoUring
Continue change options and flags to Typed types
Fix test cases to use updated IoUring flags and options
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
Improve naming and namespacing of IoUring flags and types to
match Zig Style
move some flags from uflags to its type
Add matches doc comments to make it easy to match Zig IoUring types
to liburing
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
and use linux Flags where appropriate
constants is a namespace
make AsyncCancel flags more descriptive
move cqe.flags into the Cqe type
make io_uring_sqe ioprio a packed union of SendRecv & Accept
TODO: move some of the used linux Flags to be packed structs
Signed-off-by: Bernard Assan <mega.alpha100@gmail.com>
This also unifies the rename implementations, since previously `posix.renameW` used `MoveFileEx` while `posix.renameatW` used `NtOpenFile`/`NtSetInformationFile`. This, in turn, allows the `MoveFileEx` bindings to be deleted as `posix.renameW` was the only usage.
This commit flips usage of PathType.isSep from requiring the caller to convert to native to assuming the input is LE encoded, which is a breaking change. This makes usage a bit nicer, though, and moves the endian conversion work from runtime to comptime.
When calling QueryObjectName, NT namespaced paths can be returned. This
change appropriately strips the prefix to turn it into an absolute path.
(The above behaviour was observed at least in Wine so far)
Co-authored-by: Ryan Liptak <squeek502@hotmail.com>
Previously, fs.path handled a few of the Windows path types, but not all of them, and only a few of them correctly/consistently. This commit aims to make `std.fs.path` correct and consistent in handling all possible Win32 path types.
This commit also slightly nudges the codebase towards a separation of Win32 paths and NT paths, as NT paths are not actually distinguishable from Win32 paths from looking at their contents alone (i.e. `\Device\Foo` could be an NT path or a Win32 rooted path, no way to tell without external context). This commit formalizes `std.fs.path` being fully concerned with Win32 paths, and having no special detection/handling of NT paths.
Resources on Windows path types, and Win32 vs NT paths:
- https://googleprojectzero.blogspot.com/2016/02/the-definitive-guide-on-win32-to-nt.html
- https://chrisdenton.github.io/omnipath/Overview.html
- https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file
API additions/changes/deprecations
- `std.os.windows.getWin32PathType` was added (it is analogous to `RtlDetermineDosPathNameType_U`), while `std.os.windows.getNamespacePrefix` and `std.os.windows.getUnprefixedPathType` were deleted. `getWin32PathType` forms the basis on which the updated `std.fs.path` functions operate.
- `std.fs.path.parsePath`, `std.fs.path.parsePathPosix`, and `std.fs.path.parsePathWindows` were added, while `std.fs.path.windowsParsePath` was deprecated. The new `parsePath` functions provide the "root" and the "kind" of a path, which is platform-specific. The now-deprecated `windowsParsePath` did not handle all possible path types, while the new `parsePathWindows` does.
- `std.fs.path.diskDesignator` has been deprecated in favor of `std.fs.path.parsePath`, and same deal with `diskDesignatorWindows` -> `parsePathWindows`
- `relativeWindows` is now a compile error when *not* targeting Windows, while `relativePosix` is now a compile error when targeting Windows. This is because those functions read/use the CWD path which will behave improperly when used from a system with different path semantics (e.g. calling `relativePosix` from a Windows system with a CWD like `C:\foo\bar` will give you a bogus result since that'd be treated as a single relative component when using POSIX semantics). This also allows `relativeWindows` to use Windows-specific APIs for getting the CWD and environment variables to cut down on allocations.
- `componentIterator`/`ComponentIterator.init` have been made infallible. These functions used to be able to error on UNC paths with an empty server component, and on paths that were assumed to be NT paths, but now:
+ We follow the lead of `RtlDetermineDosPathNameType_U`/`RtlGetFullPathName_U` in how it treats a UNC path with an empty server name (e.g. `\\\share`) and allow it, even if it'll be invalid at the time of usage
+ Now that `std.fs.path` assumes paths are Win32 paths and not NT paths, we don't have to worry about NT paths
Behavior changes
- `std.fs.path` generally: any combinations of mixed path separators for UNC paths are universally supported, e.g. `\/server/share`, `/\server\share`, `/\server/\\//share` are all seen as equivalent UNC paths
- `resolveWindows` handles all path types more appropriately/consistently.
+ `//` and `//foo` used to be treated as a relative path, but are now seen as UNC paths
+ If a rooted/drive-relative path cannot be resolved against anything more definite, the result will remain a rooted/drive-relative path.
+ I've created [a script to generate the results of a huge number of permutations of different path types](https://gist.github.com/squeek502/9eba7f19cad0d0d970ccafbc30f463bf) (the result of running the script is also included for anyone that'd like to vet the behavior).
- `dirnameWindows` now treats the drive-relative root as the dirname of a drive-relative path with a component, e.g. `dirname("C:foo")` is now `C:`, whereas before it would return null. `dirnameWindows` also handles local device paths appropriately now.
- `basenameWindows` now handles all path types more appropriately. The most notable change here is `//a` being treated as a partial UNC path now and therefore `basename` will return `""` for it, whereas before it would return `"a"`
- `relativeWindows` will now do its best to resolve against the most appropriate CWD for each path, e.g. relative for `D:foo` will look at the CWD to check if the drive letter matches, and if not, look at the special environment variable `=D:` to get the shell-defined CWD for that drive, and if that doesn't exist, then it'll resolve against `D:\`.
Implementation details
- `resolveWindows` previously looped through the paths twice to build up the relevant info before doing the actual resolution. Now, `resolveWindows` iterates backwards once and keeps track of which paths are actually relevant using a bit set, which also allows it to break from the loop when it's no longer possible for earlier paths to matter.
- A standalone test was added to test parts of `relativeWindows` since the CWD resolution logic depends on CWD information from the PEB and environment variables
Edge cases worth noting
- A strange piece of trivia that I found out while working on this is that it's technically possible to have a drive letter that it outside the intended A-Z range, or even outside the ASCII range entirely. Since we deal with both WTF-8 and WTF-16 paths, `path[0]`/`path[1]`/`path[2]` will not always refer to the same bits of information, so to get consistent behavior, some decision about how to deal with this edge case had to be made. I've made the choice to conform with how `RtlDetermineDosPathNameType_U` works, i.e. treat the first WTF-16 code unit as the drive letter. This means that when working with WTF-8, checking for drive-relative/drive-absolute paths is a bit more complicated. For more details, see the lengthy comment in `std.os.windows.getWin32PathType`
- `relativeWindows` will now almost always be able to return either a fully-qualified absolute path or a relative path, but there's one scenario where it may return a rooted path: when the CWD gotten from the PEB is not a drive-absolute or UNC path (if that's actually feasible/possible?). An alternative approach to this scenario might be to resolve against the `HOMEDRIVE` env var if available, and/or default to `C:\` as a last resort in order to guarantee the result of `relative` is never a rooted path.
- Partial UNC paths (e.g. `\\server` instead of `\\server\share`) are a bit awkward to handle, generally. Not entirely sure how best to handle them, so there may need to be another pass in the future to iron out any issues that arise. As of now the behavior is:
+ For `relative`, any part of a UNC disk designator is treated as the "root" and therefore isn't applicable for relative paths, e.g. calling `relative` with `\\server` and `\\server\share` will result in `\\server\share` rather than just `share` and if `relative` is called with `\\server\foo` and `\\server\bar` the result will be `\\server\bar` rather than `..\bar`
+ For `resolve`, any part of a UNC disk designator is also treated as the "root", but relative and rooted paths are still elligable for filling in missing portions of the disk designator, e.g. `resolve` with `\\server` and `foo` or `\foo` will result in `\\server\foo`
Fixes#25703Closes#25702
- Affects the following functions:
+ `std.fs.Dir.readLinkW`
+ `std.os.windows.ReadLink`
+ `std.os.windows.ntToWin32Namespace`
+ `std.posix.readlinkW`
+ `std.posix.readlinkatW`
Each of these functions (except `ntToWin32Namespace`) took WTF-16 as input and would output WTF-8, which makes optimal buffer re-use difficult at callsites and could force unnecessary WTF-16 <-> WTF-8 conversion during an intermediate step.
The functions have been updated to output WTF-16, and also allow for the path and the output to re-use the same buffer (i.e. in-place modification), which can reduce the stack usage at callsites. For example, all of `std.fs.Dir.readLink`/`readLinkZ`/`std.posix.readlink`/`readlinkZ`/`readlinkat`/`readlinkatZ` have had their stack usage reduced by one PathSpace struct (64 KiB) when targeting Windows.
The new `ntToWin32Namespace` takes an output buffer and returns a slice from that instead of returning a PathSpace, which is necessary to make the above possible.
The reasoning in the comment deleted by this commit no longer applies, since that same benefit can be obtained by using OpenFile with `.filter = .any`.
Also removes a stray debug.print
