https://bugs.winehq.org/show_bug.cgi?id=50804
Bug ID: 50804 Summary: LTSpice XVII will not start Product: Wine Version: 6.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: will.nilges@gmail.com Distribution: ---
Created attachment 69614 --> https://bugs.winehq.org/attachment.cgi?id=69614 .desktop startup errors
After installing LTSpice (which appears to work fine), the program will not start, failing silently if you use the provided .desktop file (either of them), and giving little helpful output otherwise.
I believe that LTSpice worked fine on some earlier version of Wine 6. 6.1 seems to work.
A possibly related issue is that the installer complains at you with the following message:
"You have User Account Control (UAC) enabled but did not 'Run As Administrator'
If you want to try to install in a directory you have full permissions, press 'YES' to continue anyway."
I'm running Fedora 33 with GNOME on Wayland. This happens on any of my Fedora GNOME computers. I have tried no other operating system.
My current workaround is to downgrade to Wine 5.18.
https://bugs.winehq.org/show_bug.cgi?id=50804
will.nilges@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |will.nilges@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=50804
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox.xerox2000x@gmail.com
--- Comment #1 from Louis Lenders xerox.xerox2000x@gmail.com --- Hi, cpuld you provide exact downloadlink of the programme as it seems to be free?
I tried https://ltspice.analog.com/software/LTspiceXVII.exe
but had no problems starting it directly.
Could you try start run it directly (cd into ~/.wine/drive_c/Program\ Files/LTC/LTspiceXVII/ and do wine ./XVIIx64.exe )
https://bugs.winehq.org/show_bug.cgi?id=50804
Chris Caudle winehq@chriscaudle.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@chriscaudle.org
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #2 from Chris Caudle winehq@chriscaudle.org --- Created attachment 69759 --> https://bugs.winehq.org/attachment.cgi?id=69759 console output from wine 5.18, LTspice launches and runs
This is launched with env WINEPREFIX="/home/chris/.wine" /usr/bin/wine C:\\Program\ Files\\LTC\\LTspiceXVII\\XVIIx64.exe
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #3 from Chris Caudle winehq@chriscaudle.org --- Created attachment 69760 --> https://bugs.winehq.org/attachment.cgi?id=69760 console output from wine 6.3, LTspice fails to start
started with env WINEPREFIX="/home/chris/.wine" /usr/bin/wine C:\\Program\ Files\\LTC\\LTspiceXVII\\XVIIx64.exe
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #4 from Chris Caudle winehq@chriscaudle.org --- I noticed the same problem, Fedora 33 has wine 6.3 available as an update, the same installation of LTspice runs with the previous version 5.18, fails to start after updating to 6.3 (along with mingw32-wine-gecko and mingw64-wine-gecko 2.47.2).
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #5 from Chris Caudle winehq@chriscaudle.org --- (In reply to Chris Caudle from comment #4)
I noticed the same problem, Fedora 33 has wine 6.3 available as an update, the same installation of LTspice runs with the previous version 5.18, fails to start after updating to 6.3 (along with mingw32-wine-gecko and mingw64-wine-gecko 2.47.2).
I forgot to include in my previous comment that I included the console output from successfully running under 5.18 and failing to start under 6.3 for comparison.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #6 from Chris Caudle winehq@chriscaudle.org --- Adding two additional attachments, one which runs wine ./XVIIx64.exe directly from the directory where the executable is located (as opposed to using a shortcut which first exports WINEPREFIX). The second is the same, but after reinstalling with the latest installer downloaded from the ADI web site. The installer runs, but after completing with no errors reported the installed application will not run.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #7 from Chris Caudle winehq@chriscaudle.org --- Created attachment 69800 --> https://bugs.winehq.org/attachment.cgi?id=69800 output when starting directly (wine ./XVIIx64.exe)
Output when starting application directly (not using shortcut which exports WINEPREFIX) by changing to the directory where the application is installed and running wine ./XVIIx64.exe.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #8 from Chris Caudle winehq@chriscaudle.org --- Created attachment 69801 --> https://bugs.winehq.org/attachment.cgi?id=69801 output when starting directly, after re-install
Ran installer with latest downloaded 2021-04-21 from analog.com, selected to overwrite previous install. Installer completed with no errors reported. Ran directly with wine ./XVIIx64.exe, newly installed version still did not start.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #9 from Chris Caudle winehq@chriscaudle.org --- Created attachment 69802 --> https://bugs.winehq.org/attachment.cgi?id=69802 output when starting 32 bit version directly
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #10 from will.nilges@gmail.com --- These are exactly the same symptoms that I'm getting.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #11 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Chris Caudle from comment #9)
Created attachment 69802 [details] output when starting 32 bit version directly
002c:fixme:winediag:LdrInitializeThunk wine-staging 6.3 is a testing version containing experimental patches. 002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org.
Please try with wine-6.6 or wine-staging-6.6 if you prefer to.
There have been several regressions (that are fixed) lately, so wine-6.3 is really "old" in that respect.
Thanks in advance for reporting back
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #12 from Chris Caudle winehq@chriscaudle.org --- I will see if I can easily switch to 6.6. The fedora repositories have 6.3, but I do not see 6.6 in the testing repository yet, so I will have to check if I can find a copr or rawhide version of 6.6. I have not rebuilt from source before, so I'm not sure if I have all the dependencies currently setup to build 6.6.
https://bugs.winehq.org/show_bug.cgi?id=50804
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #13 from winetest@luukku.com --- bug 49108 is somehow similar.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #14 from Chris Caudle winehq@chriscaudle.org --- Created attachment 69807 --> https://bugs.winehq.org/attachment.cgi?id=69807 output from wine 6.6
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #15 from Chris Caudle winehq@chriscaudle.org --- I added an attachment with output from wine 6.6 (installed from Fedora koji build).
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #16 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Chris Caudle from comment #3)
Created attachment 69760 [details] console output from wine 6.3, LTspice fails to start
started with env WINEPREFIX="/home/chris/.wine" /usr/bin/wine C:\\Program\ Files\\LTC\\LTspiceXVII\\XVIIx64.exe
I wonder if we are talking about the same program. I get a completely different console output: 0024:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFA, 0021FEAC $016c:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION 016c:fixme:ver:GetCurrentPackageId (00000000009A0590 0000000000000000): stub 016c:fixme:shell:InitNetworkAddressControl stub 016c:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub 016c:fixme:wincodecs:jpeg_decoder_get_metadata_blocks stub
And it starts out of the box.
To reconfirm: this i sthe program right:https://ltspice.analog.com/software/LTspiceXVII.exe
If it is: Are you running this on an existing prefix?
https://bugs.winehq.org/show_bug.cgi?id=50804
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download Product|Wine |Wine-staging CC| |leslie_alistair@hotmail.com | |, z.figura12@gmail.com URL| |https://ltspice.analog.com/ | |software/LTspiceXVII.exe Status|UNCONFIRMED |NEW Component|-unknown |-unknown Ever confirmed|0 |1 Version|6.3 |6.6
--- Comment #17 from Louis Lenders xerox.xerox2000x@gmail.com --- Edit:
I can confirm it doesn`t start in Staging that you used. But vanilla wine works fine
So looks to be a problem in Staging really
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #18 from Zebediah Figura z.figura12@gmail.com --- My guess is that it was broken by wine-staging commit 811467bf6a4, and my further guess is that it won't run on Windows unless you explicitly run it with elevated privileges.
We'll need some way of explicitly elevating privileges in wine, to accompany that patch.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #19 from Chris Caudle winehq@chriscaudle.org --- (In reply to Louis Lenders from comment #17)
I can confirm it doesn`t start in Staging that you used. But vanilla wine works fine So looks to be a problem in Staging really
I am not familiar with the terminology which the project uses for the various development flows. Can you explain what is the difference between what you call "vanilla" and staging? I see on the winehq.org page that the "stable" version is 6.0, the "development" version is 6.6, but in the news items there is a notice that 6.6 is "released." I am more familiar with other projects that do not use the term "released" in association with a development version, so it would be helpful if you could clarify which version you tested when you say vanilla wine works fine.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #20 from Chris Caudle winehq@chriscaudle.org --- (In reply to Zebediah Figura from comment #18)
My guess is that it was broken by wine-staging commit 811467bf6a4, and my further guess is that it won't run on Windows unless you explicitly run it with elevated privileges.
We'll need some way of explicitly elevating privileges in wine, to accompany that patch.
How does wine handle requests to write to what would be Windows system directories? One possibility for why this program does not always trigger the problem, or trigger with the exact same symptoms, is that in most cases it only needs access to the (Windows) user directories, but when it checks for updates it needs to write to \Program Files\LTC\LTspiceXVII which would need admin privelege to write to on a Windows machine. The equivalent on my linux machine would be ~/.wine/drive_c/Program\ Files/LTC/LTspiceXVII/ which any process running under my user account should have access to. Everything under .wine/drive_c appears to have rwxrwxr-x permissions, so perhaps that is not related. Just something that came to mind regarding why the application may not behave identically on ever start.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #21 from Zebediah Figura z.figura12@gmail.com --- (In reply to Chris Caudle from comment #20)
(In reply to Zebediah Figura from comment #18)
My guess is that it was broken by wine-staging commit 811467bf6a4, and my further guess is that it won't run on Windows unless you explicitly run it with elevated privileges.
We'll need some way of explicitly elevating privileges in wine, to accompany that patch.
How does wine handle requests to write to what would be Windows system directories? One possibility for why this program does not always trigger the problem, or trigger with the exact same symptoms, is that in most cases it only needs access to the (Windows) user directories, but when it checks for updates it needs to write to \Program Files\LTC\LTspiceXVII which would need admin privelege to write to on a Windows machine. The equivalent on my linux machine would be ~/.wine/drive_c/Program\ Files/LTC/LTspiceXVII/ which any process running under my user account should have access to. Everything under .wine/drive_c appears to have rwxrwxr-x permissions, so perhaps that is not related. Just something that came to mind regarding why the application may not behave identically on ever start.
We don't actually prevent access to system files. In fact, we don't actually restrict access to anything at all just based on whether the user is reported as an administrator. However, some applications demand to be treated as one or the other, and call dedicated APIs to check the elevation of the current process.
Bug 39262 is about the other case, where the application wants to be a non-administrator. The linked wine-staging patch takes the approach of reporting all processes as non-administrator, and automatically elevating them when requested (i.e. where Windows would spawn a UAC prompt and ask for credentials). However, some applications don't use that method, and instead demand that the user uses right-click and "Run as Administrator". We'll need to implement the latter in Wine.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #22 from Chris Caudle winehq@chriscaudle.org --- (In reply to Zebediah Figura from comment #21)
We don't actually prevent access to system files. In fact, we don't actually restrict access to anything at all just based on whether the user is reported as an administrator. However, some applications demand to be treated as one or the other, and call dedicated APIs to check the elevation of the current process.
I have run this application on Windows before, both from an administrator account, and a restricted user account. From the restricted user account when the application needed to update the directories in Program Files there was a system dialog which popped up to request a login from an administrator enabled account. So maybe this problem is not related to 39262 after all.
https://bugs.winehq.org/show_bug.cgi?id=50804
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover@gmail.com Keywords| |regression
--- Comment #23 from Zebediah Figura z.figura12@gmail.com --- The message box printed on startup is caused by wine-staging commit 811467bf6a4c introducing the "server-default_integrity" patch set. That does not happen on Windows, because the application uses a manifest requesting administrator access, so a UAC prompt will appear instead. We should parse the manifest and automatically elevated the process in this case.
All this, however, is separate from and unrelated to the reported bug (and as such probably deserves a separate bug report). A bisect shows that it is caused by:
1dd4e054b832ded6f27749068038ab462779a23a is the first bad commit commit 1dd4e054b832ded6f27749068038ab462779a23a Author: Erich E. Hoover erich.e.hoover@wine-staging.com Date: Sat Feb 6 16:32:44 2021 -0700
ntdll: Treat undecoded unix symlinks as NT symlinks.
dlls/ntdll/unix/file.c | 39 ++++++++++++++++++++++++++++----------- 1 file changed, 28 insertions(+), 11 deletions(-)
Erich, would you please take a look?
For reference, I can reproduce this bug a fresh prefix, and by simply executing "wine XVIIx86.exe" from the application directory.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #24 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zebediah Figura from comment #23)
... Erich, would you please take a look?
Absolutely, sorry - been a little busy lately.
For reference, I can reproduce this bug a fresh prefix, and by simply executing "wine XVIIx86.exe" from the application directory.
Wonderful, that should make it easy for me to investigate. If that patch is the problem then it's unlikely to be the other things we talked about (possible path interpretation issues) but I'll take a look as soon as I can. Worst case is we stop reporting unix symlinks as NT symlinks, and that's not a terrible worst case.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #25 from Chris Caudle winehq@chriscaudle.org --- (In reply to Zebediah Figura from comment #23)
ntdll: Treat undecoded unix symlinks as NT symlinks.
Which symlinks get presented? Is there a way to test the hypothesis by getting rid of symlinks?
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #26 from Zebediah Figura z.figura12@gmail.com --- Well, the weird thing about this is that in theory there shouldn't be any Unix symlinks involved. The linked patch should only deal with symlinks that the user has added manually. But I did double-check the bisect; it's correct; I can only assume that there's a bug somewhere in the patch.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #27 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zebediah Figura from comment #26)
Well, the weird thing about this is that in theory there shouldn't be any Unix symlinks involved. The linked patch should only deal with symlinks that the user has added manually. But I did double-check the bisect; it's correct; I can only assume that there's a bug somewhere in the patch.
It's more likely that it's one of the "automatic" symlinks that Wine creates (Documents, Desktop, etc.), but I'll try to look into it in the next couple days.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #28 from Zebediah Figura z.figura12@gmail.com --- (In reply to Erich E. Hoover from comment #27)
(In reply to Zebediah Figura from comment #26)
Well, the weird thing about this is that in theory there shouldn't be any Unix symlinks involved. The linked patch should only deal with symlinks that the user has added manually. But I did double-check the bisect; it's correct; I can only assume that there's a bug somewhere in the patch.
It's more likely that it's one of the "automatic" symlinks that Wine creates (Documents, Desktop, etc.), but I'll try to look into it in the next couple days.
That would make sense. It seems likely we should be creating those as NT symlinks anyway, fwiw, not that it necessarily makes a difference here.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #29 from Erich E. Hoover erich.e.hoover@gmail.com --- Okay, after a ton of banging my head against the wall... This particular application is broken under this situation on Windows as well ('My Documents' symlink). I see the same behavior with this application on both Windows and wine-staging under several different test conditions: 1) directory symbolic link (broken on both) 2) junction point (works on both) 3) custom reparse point (works on both) 4) regular directory (works on both)
So, we have a few choices here: 1) we can report unix symlinks as junction points (will definitely work in this situation, but may not work in others) 2) we can report unix symlinks as custom reparse points, such as the WSL unix symlink (will definitely work in this situation, and more likely to work in others since applications check for IO_REPARSE_TAG_MOUNT_POINT and IO_REPARSE_TAG_SYMLINK) 3) we can hide unix symlinks from applications (will definitely work in "all" situations, but harder to implement and has less functionality)
#1 is the easiest, #2 gives us the most functionality, and #3 will definitely work in more situations (discussed elsewhere). I'm personally leaning towards #2, what are your thoughts Zeb?
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #30 from Hans Leidekker hans@meelstraat.net --- (In reply to Erich E. Hoover from comment #29)
So, we have a few choices here:
- we can report unix symlinks as junction points (will definitely work in
this situation, but may not work in others) 2) we can report unix symlinks as custom reparse points, such as the WSL unix symlink (will definitely work in this situation, and more likely to work in others since applications check for IO_REPARSE_TAG_MOUNT_POINT and IO_REPARSE_TAG_SYMLINK) 3) we can hide unix symlinks from applications (will definitely work in "all" situations, but harder to implement and has less functionality)
What functionality?
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #31 from Chris Caudle winehq@chriscaudle.org --- (In reply to Erich E. Hoover from comment #29)
This particular application is broken under this situation on Windows as well ('My Documents' symlink).
Should that be considered an application bug that needs to be reported to the developers? Doesn't help the existing versions of the executable of course, but they may be interested to know if there is some mistake there.
Ignoring that for the moment, how did WINE present those symlinks before? As far as I know the "My Documents" folder presented to Windows applications has been a linux filesystem symlink to ~/Documents for many years, so what changed in how the Windows applications access that directory in recent versions? And why does it only seem to affect some applications?
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #32 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Hans Leidekker from comment #30)
(In reply to Erich E. Hoover from comment #29)
... 3) we can hide unix symlinks from applications (will definitely work in "all" situations, but harder to implement and has less functionality)
What functionality?
The ability to see the link target on the PE side of things, if we hide the links then the only way to be able to interact with them is on the unix side (stat, readlink).
(In reply to Chris Caudle from comment #31)
(In reply to Erich E. Hoover from comment #29)
This particular application is broken under this situation on Windows as well ('My Documents' symlink).
Should that be considered an application bug that needs to be reported to the developers? Doesn't help the existing versions of the executable of course, but they may be interested to know if there is some mistake there.
If you are so motivated then it might be worth a try, it's an unusual situation though so they are unlikely to care.
Ignoring that for the moment, how did WINE present those symlinks before? As far as I know the "My Documents" folder presented to Windows applications has been a linux filesystem symlink to ~/Documents for many years, so what changed in how the Windows applications access that directory in recent versions? And why does it only seem to affect some applications?
In regular wine and wine-staging up until recently the symlinks were essentially hidden, the issue that's cropping up is that we're now reporting them in wine-staging as NT symlinks (this is more* appropriate, because if those symlinks cross devices and they do not appear as reparse points then that can cause issues). Old applications that are completely unaware of reparse points work just fine, but "new-ish" applications may support one type of reparse points but not others. It is very common for these applications that are reparse-aware to behave as follows: 1) 0: normal file, don't do anything special 2) IO_REPARSE_TAG_MOUNT_POINT: read the junction point and (usually) get the real path to the target 3) IO_REPARSE_TAG_SYMLINK: read the symlink and (usually) get the real path to the target 4) other: either ignore or get the volume the target is on (unusual for this to matter, really only affects applications that search disks by file id)
* It is conceivable to treat them as other types of reparse points, but each type has pluses and minuses.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #33 from Zebediah Figura z.figura12@gmail.com --- Do you know exactly what this application is trying to do with the symlink? I.e. it's explicitly reading the target, but what for, what is it trying to do with it?
The idea of hiding unix symlinks completely still makes me nervous. Like I said in bug 50586, it doesn't "definitely work in "all" situations", it breaks GetVolumePathName() which will now always report the symlink, and then subsequent calls to e.g. GetVolumeNameForVolumeMountPoint() will fail.
I don't know, maybe this doesn't affect anything; maybe we can try it in wine-staging for a while. But it feels easier to justify breaking the applications that are actually broken.
It would also be nice to have a way to actually create usable symlinks for "My Documents" etc. from shell32.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #34 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zebediah Figura from comment #33)
Do you know exactly what this application is trying to do with the symlink? I.e. it's explicitly reading the target, but what for, what is it trying to do with it?
Nope, the application doesn't try to read the symlink. It uses FindFirstFileEx on it and sees that Reserved0 == IO_REPARSE_TAG_SYMLINK, once it detects that it calls GetFileInformationByHandle and then appears to fail in some way in the application logic (but not due to anything I can see in GetFileInformationByHandle).
The idea of hiding unix symlinks completely still makes me nervous. Like I said in bug 50586, it doesn't "definitely work in "all" situations", it breaks GetVolumePathName() which will now always report the symlink, and then subsequent calls to e.g. GetVolumeNameForVolumeMountPoint() will fail.
Right.
I don't know, maybe this doesn't affect anything; maybe we can try it in wine-staging for a while. But it feels easier to justify breaking the applications that are actually broken.
I'd say before we move to hiding them that IO_REPARSE_TAG_LX_SYMLINK might be something to try first, that way we still have the ability to read/write them on the PE side if we want/need to.
It would also be nice to have a way to actually create usable symlinks for "My Documents" etc. from shell32.
Nothing prohibits us from doing this once the reparse point support is in place. In this particular case, if we were to do so and create the link with IO_REPARSE_TAG_MOUNT_POINT then it would make this application happy. If you like then I could probably add that without too much trouble and we can ignore user-created unix symlinks for now.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #35 from Zebediah Figura z.figura12@gmail.com --- (In reply to Erich E. Hoover from comment #34)
(In reply to Zebediah Figura from comment #33)
Do you know exactly what this application is trying to do with the symlink? I.e. it's explicitly reading the target, but what for, what is it trying to do with it?
Nope, the application doesn't try to read the symlink. It uses FindFirstFileEx on it and sees that Reserved0 == IO_REPARSE_TAG_SYMLINK, once it detects that it calls GetFileInformationByHandle and then appears to fail in some way in the application logic (but not due to anything I can see in GetFileInformationByHandle).
It'd be nice to know what it's trying to do, just to make sure it's not our bug, but I can also accept that applications are thrown off by trying to handle symlinks and doing it wrong somehow.
The idea of hiding unix symlinks completely still makes me nervous. Like I said in bug 50586, it doesn't "definitely work in "all" situations", it breaks GetVolumePathName() which will now always report the symlink, and then subsequent calls to e.g. GetVolumeNameForVolumeMountPoint() will fail.
Right.
I don't know, maybe this doesn't affect anything; maybe we can try it in wine-staging for a while. But it feels easier to justify breaking the applications that are actually broken.
I'd say before we move to hiding them that IO_REPARSE_TAG_LX_SYMLINK might be something to try first, that way we still have the ability to read/write them on the PE side if we want/need to.
Yes, I'd be inclined to agree. Having seen multiple applications break because they try to handle symlinks and do it wrong, I'm increasingly inclined to advocate for using IO_REPARSE_TAG_LX_SYMLINK or a custom tag.
That said, do we know whether kernel32 handles arbitrary reparse tags transparently? I don't see tests for that in the wine-staging patch set, although I may just be overlooking them.
It would also be nice to have a way to actually create usable symlinks for "My Documents" etc. from shell32.
Nothing prohibits us from doing this once the reparse point support is in place. In this particular case, if we were to do so and create the link with IO_REPARSE_TAG_MOUNT_POINT then it would make this application happy. If you like then I could probably add that without too much trouble and we can ignore user-created unix symlinks for now.
I don't think we should use IO_REPARSE_TAG_MOUNT_POINT; that has special meaning to volume functions.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #36 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zebediah Figura from comment #35)
... It'd be nice to know what it's trying to do, just to make sure it's not our bug, but I can also accept that applications are thrown off by trying to handle symlinks and doing it wrong somehow.
Yeah, I spent quite a while trying to figure that out before I tested on Windows (it took me an embarrassingly long time to think it might be an app bug). We would probably need someone to disassemble the app, which is not something that I do with applications that I didn't make.
... I'd say before we move to hiding them that IO_REPARSE_TAG_LX_SYMLINK might be something to try first, that way we still have the ability to read/write them on the PE side every inch of you is perfect from the bottom to the topif we want/need to.
Yes, I'd be inclined to agree. Having seen multiple applications break because they try to handle symlinks and do it wrong, I'm increasingly inclined to advocate for using IO_REPARSE_TAG_LX_SYMLINK or a custom tag.
I'll investigate what to do here then, it looks like the format is pretty simple.
That said, do we know whether kernel32 handles arbitrary reparse tags transparently? I don't see tests for that in the wine-staging patch set, although I may just be overlooking them.
What kind of behavior were you thinking of? Nothing in kernel32 should really care what kind of reparse tag you have (except for using IO_REPARSE_TAG_MOUNT_POINT to find volume changes). Wine cmd is the only thing that actually _reads_ the tag and does anything with the results.
It would also be nice to have a way to actually create usable symlinks for "My Documents" etc. from shell32.
Nothing prohibits us from doing this once the reparse point support is in place. In this particular case, if we were to do so and create the link with IO_REPARSE_TAG_MOUNT_POINT then it would make this application happy. If you like then I could probably add that without too much trouble and we can ignore user-created unix symlinks for now.
I don't think we should use IO_REPARSE_TAG_MOUNT_POINT; that has special meaning to volume functions.
I would have proposed IO_REPARSE_TAG_SYMLINK until we encountered this bug. Once I add support for it, IO_REPARSE_TAG_LX_SYMLINK could do the trick. As the code currently stands it's working with unix paths, but we might need to get clever when shell32 gets converted to PE.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #37 from Zebediah Figura z.figura12@gmail.com --- (In reply to Erich E. Hoover from comment #36)
(In reply to Zebediah Figura from comment #35)
... It'd be nice to know what it's trying to do, just to make sure it's not our bug, but I can also accept that applications are thrown off by trying to handle symlinks and doing it wrong somehow.
Yeah, I spent quite a while trying to figure that out before I tested on Windows (it took me an embarrassingly long time to think it might be an app bug). We would probably need someone to disassemble the app, which is not something that I do with applications that I didn't make.
... I'd say before we move to hiding them that IO_REPARSE_TAG_LX_SYMLINK might be something to try first, that way we still have the ability to read/write them on the PE side every inch of you is perfect from the bottom to the topif we want/need to.
Yes, I'd be inclined to agree. Having seen multiple applications break because they try to handle symlinks and do it wrong, I'm increasingly inclined to advocate for using IO_REPARSE_TAG_LX_SYMLINK or a custom tag.
I'll investigate what to do here then, it looks like the format is pretty simple.
That said, do we know whether kernel32 handles arbitrary reparse tags transparently? I don't see tests for that in the wine-staging patch set, although I may just be overlooking them.
What kind of behavior were you thinking of? Nothing in kernel32 should really care what kind of reparse tag you have (except for using IO_REPARSE_TAG_MOUNT_POINT to find volume changes). Wine cmd is the only thing that actually _reads_ the tag and does anything with the results.
I forgot that kernel32 doesn't ever use FSCTL_GET_REPARSE_POINT, though even then it'd probably be a good idea to make sure that windows kernel32 is otherwise agnostic about the actual tag. (Incidentally I don't know if there are exhaustive tests for *all* kernel32 path/file functions with symlinks, but there really should be.)
I would have proposed IO_REPARSE_TAG_SYMLINK until we encountered this bug. Once I add support for it, IO_REPARSE_TAG_LX_SYMLINK could do the trick. As the code currently stands it's working with unix paths, but we might need to get clever when shell32 gets converted to PE.
PE conversion is the main reason, yes. Ideally we should use FSCTL_SET_REPARSE_POINT in place of symlink(2).
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #38 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zebediah Figura from comment #37)
... I forgot that kernel32 doesn't ever use FSCTL_GET_REPARSE_POINT, though even then it'd probably be a good idea to make sure that windows kernel32 is otherwise agnostic about the actual tag. (Incidentally I don't know if there are exhaustive tests for *all* kernel32 path/file functions with symlinks, but there really should be.)
Yeah, it has CreateSymbolicLink for FSCTL_SET_REPARSE_POINT - but I am not aware of any routines that actually _read_ them without going into ntdll. FindNextFileW does so currently, but it can be implemented without that because it only looks at the tag (on my list to simplify).
I would have proposed IO_REPARSE_TAG_SYMLINK until we encountered this bug. Once I add support for it, IO_REPARSE_TAG_LX_SYMLINK could do the trick. As the code currently stands it's working with unix paths, but we might need to get clever when shell32 gets converted to PE.
PE conversion is the main reason, yes. Ideally we should use FSCTL_SET_REPARSE_POINT in place of symlink(2).
Yup, that's what I'll do - the thing that will get tricky is that when shell32 gets converted to PE that we'll need a way to properly convey the paths. IO_REPARSE_TAG_LX_SYMLINK works with straight-up unix paths (what we use right now), I assume that when this is converted to PE that we'll want to work with NT paths (though maybe we work with the "\??\unix" prefix when that happens?).
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #39 from Zebediah Figura z.figura12@gmail.com --- (In reply to Erich E. Hoover from comment #38)
Yup, that's what I'll do - the thing that will get tricky is that when shell32 gets converted to PE that we'll need a way to properly convey the paths. IO_REPARSE_TAG_LX_SYMLINK works with straight-up unix paths (what we use right now), I assume that when this is converted to PE that we'll want to work with NT paths (though maybe we work with the "\??\unix" prefix when that happens?).
shell32 should probably use ??\unix paths in general (or even straight up "/foo/bar" paths where possible, which ntdll converts to ??\unix/foo/bar). As for reparse points, I'm not sure whether Unix paths or NT paths makes more sense for IO_REPARSE_TAG_LX_SYMLINK, probably the answer is 'whatever is easier'.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #40 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Zebediah Figura from comment #39)
(In reply to Erich E. Hoover from comment #38)
Yup, that's what I'll do - the thing that will get tricky is that when shell32 gets converted to PE that we'll need a way to properly convey the paths. IO_REPARSE_TAG_LX_SYMLINK works with straight-up unix paths (what we use right now), I assume that when this is converted to PE that we'll want to work with NT paths (though maybe we work with the "\??\unix" prefix when that happens?).
shell32 should probably use ??\unix paths in general (or even straight up "/foo/bar" paths where possible, which ntdll converts to ??\unix/foo/bar). As for reparse points, I'm not sure whether Unix paths or NT paths makes more sense for IO_REPARSE_TAG_LX_SYMLINK, probably the answer is 'whatever is easier'.
On Windows IO_REPARSE_TAG_LX_SYMLINK is a normal unix path (prefixed by '/mnt' because of the way WSL is set up), so if shell32 is reworked to use ??\unix/foo/bar then it's pretty easy for us to strip "??\unix" before passing the path to FSCTL_SET_REPARSE_POINT.
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #41 from Chris Caudle winehq@chriscaudle.org --- Have any of the recent versions incorporated any changes to this? Any reason for me to retest with 6.9?
https://bugs.winehq.org/show_bug.cgi?id=50804
--- Comment #42 from Chris Caudle winehq@chriscaudle.org --- (In reply to Chris Caudle from comment #41)
Have any of the recent versions incorporated any changes to this? Any reason for me to retest with 6.9?
I just tried and LTSpice does start with 6.9 (using Fedora F34 build wine-6.9-1.fc34.x86_64 ).
https://bugs.winehq.org/show_bug.cgi?id=50804
Erich E. Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Regression SHA1| |750044c08c49c7a117fcc911506 | |a198969379144 Fixed by SHA1| |8e5c8cc63b57dbe9b2cf2ff075c | |12648845b22fa Resolution|--- |FIXED
--- Comment #43 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Chris Caudle from comment #42)
(In reply to Chris Caudle from comment #41)
Have any of the recent versions incorporated any changes to this? Any reason for me to retest with 6.9?
I just tried and LTSpice does start with 6.9 (using Fedora F34 build wine-6.9-1.fc34.x86_64 ).
Yes, sorry - been a busy week. I'll go ahead and mark this as resolved.
https://bugs.winehq.org/show_bug.cgi?id=50804
Erich E. Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #44 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Chris Caudle from comment #42)
(In reply to Chris Caudle from comment #41)
Have any of the recent versions incorporated any changes to this? Any reason for me to retest with 6.9?
I just tried and LTSpice does start with 6.9 (using Fedora F34 build wine-6.9-1.fc34.x86_64 ).
Closing bug, fixed in wine-staging 6.9
-
WineHQ Bugzilla