Implement readlink on Windows #5879
Conversation
|
OK @andrewrk I think this is ready for the next round review. I've managed to re-implement Also, one thing I'm still unsure about is the behaviour of Anyhow, have a look at the PR and let me know what you reckon! |
daurnimator
added
os-windows
standard library
This way `std.fs.symlinkAbsolute` becomes cross-platform and we can legally include `SymlinkFlags` as an argument that's only used on Windows. Also, now `std.os.symlink` generates a compile error on Windows with a message to instead use `std.os.windows.CreateSymbolicLink`. Finally, this PR also reshuffles the tests between `std.os.test` and `std.fs.test`.
Otherwise, the behaviour can lead to unexpected results, resulting in removing an entire tree that's not necessarily under the root. Furthermore, this change is needed if are to properly handle dir symlinks on Windows. Without explicitly requiring that a directory or file is opened with `FILE_OPEN_REPARSE_POINT`, Windows automatically dereferences all symlinks along the way. This commit adds another option to `OpenDirOptions`, namely `.no_follow`, which defaults to `false` and can be used to specifically open a directory symlink on Windows or call `openat` with `O_NOFOLLOW` flag in POSIX.
Fix WASI build, fix atomicSymlink by using `cwd().symLink`, add `Dir.symLink` on supported targets.
|
@kubkon this is really, really nice work. This is a big deal for the |
This rather lengthy PR adds
std.os.readlinksupport to Windows. At the same time, while developing basic smoke tests, this PR also reworkssymlinkon Windows, which now takes into account the updated Windows API. Finally, I've discovered after many failed attempts that on Windows, prepending\??\is valid whenever we pass in the (absolute) path to NT-based syscalls such asNtCreateFile, however, this is no longer true when interacting withWin32wrappers. It became apparent that when usingstd.os.windows.sliceToPrefixedFileW, the generated path passed toCreateSymbolicLinkWwould be incorrectly treated as a relative path even thought it was absolute. Replacing the prefix from\??\to\\?\as described in MSDN manual fixed this behaviour. Therefore, I've added two new helper functions tostd.os.windowsmodule, namelysliceToWin32PrefixedFileWandcStrToWin32PrefixedFileWwhich behave exactly the same assliceToPrefixedFileWandcStrToPrefixedFileWbut prepend\\?\instead. I guess it would be beneficial to renamesliceToPrefixedFileWinto something likesliceToNtPrefixedFileWbut IMHO this is job for a subsequent PR.Aside from the above, this PR also tweaks and fixes:
std.os.unlinkatWto includeFILE_OPEN_REPARSE_POINTflag without which deleting the actual symlink usingNtCreateFilewill erroneously delete the target or fail with error if the target is already gone,std.os.symlink, namely,SymlinkFlagsstruct which is can be used to specify whether the symlink is meant to point at a file or directory. On Windows, it is an error if one tries to create a symlink to a directory without passing an appropriate flag toCreateSymbolicLinkW. This change is up for debate. In Rust, there are two Windows-only functions that achieve the samesymlink_fileandsymlink_dir. Here I thought it'd be nice if we could instead provide a common interface across hosts, however, differentiate with flags which would be used only on selected hosts (here, this would only be Windows). However, there's still the remaning question of how do we handle disparity in error generation between hosts. POSIX has only one syscall which issymlinkwhich can be used to create symlinks to both files and dirs, whereas on Windows, callingsymlinkwithout directory flags will likely cause an error. This one I still need to figure out but perhaps in a subsequent PR.FILE_TRANSACTED_MODEflag withFILE_OPEN_REPARSE_POINTflag instd.os.windows.bits. I couldn't find any mention of the former on MSDN, while at the same time,0x00200000is reserved forFILE_OPEN_REPARSE_POINTflag to be used inNtCreateFilesyscall when opening the actual reparse point (symbolic link)I'm not sure who to ask to review this, but if anyone who feels well-acquainted with Windows programming could have a look, that'd be awesome!