https://bugs.winehq.org/show_bug.cgi?id=56647
--- Comment #2 from Lorenzo Ferrillo lorenzofer@live.it --- I have another issue related to this patchset and Rust, in particular the tool cargo from Nightlies after 05 May 2024, when the code you are compiling is on a directory with part of the path on a different drive (in my case was in a subdir of Z:\home)
This particualr issue start from the 0005 patch of the patchset: Subject: [PATCH] server: Implement FILE_OPEN_REPARSE_POINT option.
In particular adding the FILE_OPEN_REPARSE_POINT to kernelbase, this cause this path to be considered a reparse point and assigned the FILE_ATTRIBUTE_REPARSE_POINT flag.
This cause cargo to ask for a NtQueryInformationFile with FileAttributeTagInformation (in addition to FileStatInformation) If this return IO_REPARSE_TAG_MOUNT_POINT, as it's in this case, it try to get the Reparse Point info with FSCTL_GET_REPARSE_POINT where the flow is failing on readlink (as linux mountpoints aren't symlinks)
Note that even FileStatInformation have a ReparseTag that can contain IO_REPARSE_TAG_MOUNT_POINT, but that it's used at all, preferring FileAttributeTagInformation.
If I avoid returning IO_REPARSE_TAG_MOUNT_POINT from FileAttributeTagInformation, cargo start to work again If I globally avoid FILE_OPEN_REPARSE_POINT in get_nt_file_options, it works and avoid the call for FileAttributeTagInformation If I avoid setting FILE_ATTRIBUTE_REPARSE_POINT in fd_get_file_info beheaviour is like the previous one.
I see different mode to proceed: The first would be to avoid setting IO_REPARSE_TAG_MOUNT_POINT, either in the specific sections or stubbing fd_is_mount_point, both situation would effectively return to the previous situation without FILE_OPEN_REPARSE_POINT implemented (the code to set IO_REPARSE_TAG_MOUNT_POINT was there is various zone but "dead" becouse conditioned on this flag ) or to try to implement this case (with the risk of opening another can of worms)