[Bug 56647] New: ntdll-Junction_Points prevent rustup from correctly installing a toolchain
https://bugs.winehq.org/show_bug.cgi?id=56647 Bug ID: 56647 Summary: ntdll-Junction_Points prevent rustup from correctly installing a toolchain Product: Wine-staging Version: 9.8 Hardware: x86-64 URL: https://rustup.rs/ OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: lorenzofer(a)live.it CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: ArchLinux Created attachment 76423 --> https://bugs.winehq.org/attachment.cgi?id=76423 return STATUS_NOT_A_REPARSE_POINT instead of STATUS_INVALID_PARAMETER Hi. With the recent rustup 1.27.0 using wine-staging with the ntdll-Junction_Points patches, the toolchain installation doesn't complete properly, failing to write to the settings.toml under the prefix home .rustup directory info. A bug with the same root cause is also present on rustup 1.26.0 where while the installation was completing properly, it was failing to remove the .rustup/tmp/* directories, causing issues with subsequent installations. Both bugs express the same behavioral pattern with few differences. I investigated the directory bug firstly, so I will detail this, and confirmed that the problem and the expected solution are the same. Rustup (or one of it's dependency managing files) get the handle of the temporary directory using CreateFileW and then checking if it's a reparse point using DeviceIoControl with FSCTL_GET_REPARSE_POINT. The directories (and the file) aren't reparse points at all, so the readlink fails returining EINVAL. This EINVAL is then mapped to an NT_STATUS using errno_to_status that map EINVAL to STATUS_INVALID_PARAMETER. However this mapping is incorrect for FSCTL_GET_REPARSE_POINT as in this case applications that handle this case like rustup try to handle this case by epxecting STATUS_NOT_A_REPARSE_POINT. Returning STATUS_NOT_A_REPARSE_POINT in this case allow rustup to work (both versions ) Attaching a patch to show the change in the file.c code (and restored also the out_buffer check) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56647 Lorenzo Ferrillo <lorenzofer(a)live.it> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56647 --- Comment #1 from Lorenzo Ferrillo <lorenzofer(a)live.it> --- CCing Erich E. Hoover as the maker of the patchset -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56647 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56647 --- Comment #2 from Lorenzo Ferrillo <lorenzofer(a)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) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56647 --- Comment #3 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to Lorenzo Ferrillo from comment #2)
... 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) ...
It's been a while since I've looked at this, but I thought I had it set up to return an IO_REPARSE_TAG_LX_SYMLINK (WSL Linux Symlink)... I'll try to take a look at these issues this weekend, but if it's failing to "convert" unix symlinks (or I forgot to add that patch) then that could explain the issue here. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56647 --- Comment #4 from Lorenzo Ferrillo <lorenzofer(a)live.it> --- Eric the issue here is that these folders aren't symlinks, they are unix mountpoints, and readlink doesn't work for them. IO_REPARSE_TAG_MOUNT_POINT is setted only if S_ISDIR is true and the folder device is different then the parent device, or their inode are the same. The function for that is fd_is_mount_point and pre-exist the ntdll_Junction-Points patchset however they weren't actually setted without implementing FILE_OPEN_REPARSE_POINT usage. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56647 --- Comment #5 from Erich E. Hoover <erich.e.hoover(a)gmail.com> --- (In reply to Lorenzo Ferrillo from comment #4)
Eric the issue here is that these folders aren't symlinks, they are unix mountpoints, and readlink doesn't work for them. IO_REPARSE_TAG_MOUNT_POINT is setted only if S_ISDIR is true and the folder device is different then the parent device, or their inode are the same. The function for that is fd_is_mount_point and pre-exist the ntdll_Junction-Points patchset however they weren't actually setted without implementing FILE_OPEN_REPARSE_POINT usage.
Oh, I thought you were talking about a symlink to a different drive. I'll have to think about how a real mount point should behave here... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56647 radek(a)podgorny.cz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |radek(a)podgorny.cz -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56647 --- Comment #6 from radek(a)podgorny.cz --- what can i do to move this forward? being unable to install rust toolchain in wine really complicates my linux-to-windows cross-compilation build chain. thanks! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56647 --- Comment #7 from Lorenzo Ferrillo <lorenzofer(a)live.it> --- Created attachment 77932 --> https://bugs.winehq.org/attachment.cgi?id=77932 Don't return IO_REPARSE_TAG_MOUNT_POINT for linux mount -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56647 Lorenzo Ferrillo <lorenzofer(a)live.it> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #77932|0 |1 is patch| | Attachment #77932|application/mbox |text/plain mime type| | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56647 --- Comment #8 from Lorenzo Ferrillo <lorenzofer(a)live.it> --- Created attachment 77933 --> https://bugs.winehq.org/attachment.cgi?id=77933 Don't return FILE_ATTRIBUTE_REPARSE_POINT if unix mountpoint -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=56647 --- Comment #9 from Lorenzo Ferrillo <lorenzofer(a)live.it> --- Hi radek. I'm building wine-staging on top of ntdll-Junction Points patchset with these 2 patches I attached before (the one on the first comment of the bug should already be included IIRC in the patchset itself) and rustup works, at least version 1.27. These patches make wine treat unix mountpoints trasparently, instead of reporting them as mount reparse point. It's probably not correct, the most correct way should be to really treat them as reparse points, however the patchset and wine itself lack the infrastructure to do so, so they error when trying to use FSCTL_GET_REPARSE_POINT and FSCTL_SET_REPARSE_POINT stuffs. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=56647 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |b0595d928b6b8c8af8a8b3d5a7c | |4966159a3adcf Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #10 from Zeb Figura <z.figura12(a)gmail.com> --- The originally reported fix was committed into wine-staging 9.9 as b0595d928b6b8c8af8a8b3d5a7c4966159a3adcf. That's been incorporated as junction point support was upstreamed, and I can confirm rustup still works. The bug reported in comment 2 is a separate problem, which I believe is still not addressed upstream. It's also essentially tracked by bug 54903 anyway. Therefore I'm resolving this FIXED. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla