[Bug 56647] New: ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

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: [e-mail]
          Reporter: [e-mail]
                CC: [e-mail], [e-mail]
      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)

[Bug 56647] ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56647

Lorenzo Ferrillo  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 56647] ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56647

--- Comment #1 from Lorenzo Ferrillo  ---
CCing Erich E. Hoover as the maker of the patchset

[Bug 56647] ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56647

Ken Sharp  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |download, source

[Bug 56647] ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56647

--- Comment #2 from Lorenzo Ferrillo  ---
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)

[Bug 56647] ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56647

--- Comment #3 from Erich E. Hoover  ---
(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.

[Bug 56647] ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56647

--- Comment #4 from Lorenzo Ferrillo  ---
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.

[Bug 56647] ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56647

--- Comment #5 from Erich E. Hoover  ---
(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...

[Bug 56647] ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56647

[e-mail] changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 56647] ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56647

--- Comment #6 from [e-mail] ---
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!

[Bug 56647] ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56647

--- Comment #7 from Lorenzo Ferrillo  ---
Created attachment 77932
  --> https://bugs.winehq.org/attachment.cgi?id=77932
Don't return IO_REPARSE_TAG_MOUNT_POINT for linux  mount

[Bug 56647] ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56647

Lorenzo Ferrillo  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #77932|0                           |1
           is patch|                            |
  Attachment #77932|application/mbox            |text/plain
          mime type|                            |

[Bug 56647] ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56647

--- Comment #8 from Lorenzo Ferrillo  ---
Created attachment 77933
  --> https://bugs.winehq.org/attachment.cgi?id=77933
Don't return FILE_ATTRIBUTE_REPARSE_POINT if unix mountpoint

[Bug 56647] ntdll-Junction_Points prevent rustup from correctly installing a toolchain

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=56647

--- Comment #9 from Lorenzo Ferrillo  ---
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.