https://bugs.winehq.org/show_bug.cgi?id=53093
Bug ID: 53093 Summary: Simple command that needs CreateSymbolicLinkW doesn`t work anymore in Staging Product: Wine Version: 7.9 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: xerox.xerox2000x@gmail.com Distribution: Debian
Also see https://bugs.winehq.org/show_bug.cgi?id=47100
The simple command from that bugreport again doesn`t work anymore;
cd $(mktemp -d) && wine cmd /C "mklink foo bar" && stat foo
So programs that need this are broken again I guess?
https://bugs.winehq.org/show_bug.cgi?id=53093
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Product|Wine |Wine-staging Component|-unknown |-unknown CC| |leslie_alistair@hotmail.com | |, z.figura12@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=53093
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover@gmail.com
--- Comment #1 from Louis Lenders xerox.xerox2000x@gmail.com --- I just downloaded some Staging versions from https://github.com/Kron4ek/Wine-Builds to check in which versions it worked, and after a few tries I got:
wine-Staging-6.14: works fine
wine-Staging-6.15: the command fails.
So the regression is somehow introduced into wine-Staging-6.15
Erich, hope you don`t mind I added you to bugreport; any chance you could have a look?
https://bugs.winehq.org/show_bug.cgi?id=53093
--- Comment #2 from Louis Lenders xerox.xerox2000x@gmail.com --- Created attachment 72522 --> https://bugs.winehq.org/attachment.cgi?id=72522 +file,+relay,+server
Attached +file,+relay,+server log
Seems like NtFsControlFile returns c0000005, but I don`t know why it fails
0100:trace:file:DeviceIoControl (00000084,900a4,009D95B0,36,00000000,0,008AA794,00000000) 0100:Call ntdll.NtFsControlFile(00000084,00000000,00000000,00000000,008aa708,000900a4,009d95b0,00000024,00000000,00000000) ret =7b023dab 0100:trace:file:NtFsControlFile (0x84,(nil),(nil),(nil),0x8aa708,0x000900a4,0x9d95b0,0x00000024,(nil),0x00000000) 0100: get_handle_fd( handle=0084 ) 0100: *fd* 0084 -> 254 0100: get_handle_fd() = 0 { type=1, cacheable=1, access=0012019f, options=00204020 } 0100: get_handle_unix_name( handle=0084, nofollow=0 ) 0100: get_handle_unix_name() = 0 { name_len=62, name="/home/louis/ramdisk/.wine/dosdevices/z:/home/louis/ramdisk/foo" } 0100:trace:file:find_drive_rootA "/home/louis/ramdisk/.wine/dosdevices/z:/home/louis/ramdisk/" -> drive Z:, root="/home/louis/ ramdisk/.wine/dosdevices/z:", name="/home/louis/ramdisk/" 0100:Ret ntdll.NtFsControlFile() retval=c0000005 ret=7b023dab
https://bugs.winehq.org/show_bug.cgi?id=53093
--- Comment #3 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Louis Lenders from comment #1)
... Erich, hope you don`t mind I added you to bugreport; any chance you could have a look?
Yup, I'll try to look at it in the next couple days. I have some other updates to this that I haven't had a chance to get to either :/
https://bugs.winehq.org/show_bug.cgi?id=53093
--- Comment #4 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Erich E. Hoover from comment #3)
(In reply to Louis Lenders from comment #1)
... Erich, hope you don`t mind I added you to bugreport; any chance you could have a look?
Yup, I'll try to look at it in the next couple days. I have some other updates to this that I haven't had a chance to get to either :/
Great!
( FWIW someone reported this. and found that in powershell core something like "New-Item -Type SymbolicLink -Path 'C:\Test' -Value 'C:\Program Files'" doesn`t work anymore, preventing packages to install properly)
https://bugs.winehq.org/show_bug.cgi?id=53093
--- Comment #5 from Louis Lenders xerox.xerox2000x@gmail.com --- Hi Erich, any update on this one?
Regards
https://bugs.winehq.org/show_bug.cgi?id=53093
--- Comment #6 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Louis Lenders from comment #5)
Hi Erich, any update on this one?
Regards
Louis, I'm really sorry I haven't gotten to this yet. I have been absolutely swamped at work; however, I am reaching the light at the end of the tunnel. My goal is to take a look at this over the weekend and hopefully get the patchset properly updated :)
https://bugs.winehq.org/show_bug.cgi?id=53093
--- Comment #7 from Erich E. Hoover erich.e.hoover@gmail.com --- Hello everyone, sorry it's taken so long to get this done. This bug should be fixed by the latest commit to wine-staging (1ed196f0effa262b297705f36975261f44001417).
I apologize for the delay. This update ended up taking a lot more time than I expected, since the changes AJ requested ended up being more work than I had originally anticipated. However, in the end, I think that the patches are much cleaner and there is now a _much_ higher chance that this will get included into main Wine (after some testing, of course).
Summary of Changes: This is a complete rewrite of the underlying set/get reparse point behavior. Reparse point data is now encoded in the symlink target as a relative path composed of these components (slash separated): 1) .REPARSE_POINT 2) the filename of the symlink (to avoid collisions) 3) a flag to indicate whether the reparse point is a file (/) or directory (./) 4) the full reparse point buffer (base64url encoded) split into 255 byte slash-separated chunks (up to a total of 4095 bytes for all of the components of the symlink target) 5) a continuation id (0, 1, ...) for the next component (if the reparse point data is so large that it requires an additional file)
Additional (continuation) symlinks are composed of: 1) "../" (go to parent) however many times are needed to walk back up to the filename folder 2) the rest of the base64url-encoded reparse data (as much as will fit in the 4095 byte symlink target limit) 3) the next continuation id (to ensure that path collisions are impossible if there's a lot of identical data in the reparse buffer)
The final "continuation" symlink goes the target destination (if it's one of the reparse point types we understand, otherwise it's just a dangling symlink). If it's a relative symlink then it walks back up to the folder with the original symlink and appends the target from there, if it's an absolute symlink then it just goes straight to the target (absolute targets within the prefix use a special intermediary "${WINEPREFIX}" symlink to make it easy to fix the Unix symlink if a prefix gets moved to a new location). This symlink is not _necessary_ for the patches to work, but if it exists then it makes resolving the symlinks faster (with the added bonus of allowing the reparse point to work outside of Wine).
Now that we've had about 10 years to get the bugs and eccentricities of reparse points figured out, I'm hopeful that we can finally get this updated reparse point support integrated into vanilla Wine. In anticipation of that, I'm already looking at implementing the Single-Instance Store (SIS) reparse point so that we can use that feature to de-duplicate all the Wine DLLs that we currently copy into the prefix. All of this is a very long way of saying "a lot hash changed, please test this and report back with any problems".
https://bugs.winehq.org/show_bug.cgi?id=53093
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset| |1ed196f0effa262b297705f3697 | |5261f44001417 Status|NEW |STAGED
--- Comment #8 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Erich E. Hoover from comment #7)
Hi Erich,
I can confirm the bug is fixed in current Staging compiled from git. Thanks very much and really appreciate the efforts (and amount of time) you did! For now I only tested some simple PowerShell commands like New-Item -Type SymbolicLink -Path etc. (needed by some chocolatey installers) and they work.
Will also do some testing with Office365 that afaik also needs this CreatesymbolicLinkW. If I find anything I`ll report back here. Best regards!
https://bugs.winehq.org/show_bug.cgi?id=53093
Neko-san nekoNexus@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nekoNexus@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=53093
--- Comment #9 from Louis Lenders xerox.xerox2000x@gmail.com --- Hi Erich, not sure if you have time to look into this (again) but I found that there's still some commands that doesn't work for CreateSymbolicLinkW (tested in Powershell Core):
New-Item -Type SymbolicLink -Path 'C:\aa' -Value 'C:\Program Files\Common Files\Microsoft Shared'
This one claims to have created the link successfully, but I cannot cd into it, and 'ls c:\aa' says: "Get-ChildItem: Could not find a part of the path 'C:\aa'.'"
However it seems that when the targetname is shorter it succeeds for me:
New-Item -Type SymbolicLink -Path 'C:\bb' -Value 'C:\Program Files\Common Files'
Now: 'ls C:\bb' gives correctly
Directory: C:\bb
Mode LastWriteTime Length Name ---- ------------- ------ ---- d---- 9/21/2023 10:13 PM Microsoft Shared d---- 9/21/2023 10:13 PM System
for the unsuccessfull creation I can see in the .REPARSEPOINT:
$ ls -al total 12 drwxr-xr-x 2 louis louis 4096 Sep 22 14:59 . drwxr-xr-x 3 louis louis 4096 Sep 22 14:59 .. lrwxrwxrwx 1 louis louis 25 Sep 22 14:59 '${WINEPREFIX}' -> /home/louis/ramdisk/.wine lrwxrwxrwx 1 louis louis 129 Sep 22 14:59 0 -> 'AHI/AbwBzAG8AZgB0ACAAUwBoAGEAcgBlAGQAXAAAAA/${WINEPREFIX}${WINEPREFIX}/dosdevices/c:/Program Files/Common Files/Microsoft Shared/'
It looks like something got messed up or so????
https://bugs.winehq.org/show_bug.cgi?id=53093
Aida Jonikienė aidas957@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aidas957@gmail.com
--- Comment #10 from Aida Jonikienė aidas957@gmail.com --- Created attachment 75883 --> https://bugs.winehq.org/attachment.cgi?id=75883 Staging reparse point hotfix
Does this patch help at all? You have to apply this to the Wine tree after the wine-staging patches have been applied
https://bugs.winehq.org/show_bug.cgi?id=53093
--- Comment #11 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Aida Jonikienė from comment #10)
Created attachment 75883 [details] Staging reparse point hotfix
Does this patch help at all? You have to apply this to the Wine tree after the wine-staging patches have been applied
Hi Aida,
Thanks for the patch but unfortunately it doesn't work, I still get the same error:
New-Item -Type SymbolicLink -Path 'C:\aa' -Value 'C:\Program Files\Common Files\Microsoft Shared'
'ls c:\aa' : "Get-ChildItem : Could not find a part of the path 'C:\aa'.'"
Double checked using staging 6.14 (just before the regression) correctly yields:
New-Item -Type SymbolicLink -Path 'C:\aa' -Value 'C:\Program Files\Common Files\Microsoft Shared'
'ls c:\aa':
Directory: C:\aa
Mode LastWriteTime Length Name ---- ------------- ------ ---- d---- 1/16/2024 11:06 AM TextConv
https://bugs.winehq.org/show_bug.cgi?id=53093
Aida Jonikienė aidas957@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #75883|0 |1 is obsolete| |
--- Comment #12 from Aida Jonikienė aidas957@gmail.com --- Created attachment 75913 --> https://bugs.winehq.org/attachment.cgi?id=75913 Staging reparse point fixes
Can you try this patch instead? The last one fixed a different reparse point bug (this patch should fix all of the bugs I could find and the PowerShell test commands seem to work now)
https://bugs.winehq.org/show_bug.cgi?id=53093
--- Comment #13 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Aida Jonikienė from comment #12)
Created attachment 75913 [details] Staging reparse point fixes
Can you try this patch instead? The last one fixed a different reparse point bug (this patch should fix all of the bugs I could find and the PowerShell test commands seem to work now)
Yes, this one fixes the bug for me! Nice job!
Could you ask for a merge request for this patch in Staging? (Alistair)
Thanks!
https://bugs.winehq.org/show_bug.cgi?id=53093
--- Comment #14 from Zeb Figura z.figura12@gmail.com --- Can you please strip that patch down to its meaningful changes? It's difficult to review as-is.
https://bugs.winehq.org/show_bug.cgi?id=53093
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Resolution|--- |FIXED
--- Comment #15 from Louis Lenders xerox.xerox2000x@gmail.com --- This has been fixed some time ago and works again in Staging, thanks Aida/Zebediah
https://bugs.winehq.org/show_bug.cgi?id=53093
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closing Fixed wine-staging bug.