[Bug 55975] New: crash if any application during file-open dialog when $WINEPREFIX/drive_c/users/$(whoami) is renamed or does not exist
https://bugs.winehq.org/show_bug.cgi?id=55975 Bug ID: 55975 Summary: crash if any application during file-open dialog when $WINEPREFIX/drive_c/users/$(whoami) is renamed or does not exist Product: Wine Version: 8.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: alois.schloegl(a)gmail.com Distribution: --- Created attachment 75563 --> https://bugs.winehq.org/attachment.cgi?id=75563 WINEDEBUG log during winefile crash due to missing or non-matching c:/users/username directory I prepared a WINEPREFIX for a difficult to install application, and wanted to share this with other users. I made sure the other user has read permessions to all files, and the other users then copied that WINEPREFIX, so that the fileownership is change to the other user. For the other user, that application was always crashing as soon as she started the file-open dialog. The same application was working just fine for me. After changing c:\drive_c\users\YOURNAME to the other users name, and fixing all the symlinks to her $HOME directory, the application was working fine. The main issue here is the crash - without showning any meaningful error message. In order to reproduce this, start a new wineprefix, and run winefile export WINEPREFIX=$HOME/.wine.test wineboot -i winefile This was working, now rename c:\drive_c\users\YOURNAME mv $WINEPREFIX/drive_c/users/$(whoami){,-changed} winefile winefile will crash, and so will any other application as soon as you start an file selection dialog (typically "File Open"-dialog). Even saveing the backtrace was not possible. I would expect a more graceful handling of this case, either by generating the missing directory and files, or by some error dialog indicating what the problem is. -- 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=55975 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #1 from Fabian Maurer <dark.shadow4(a)web.de> --- Created attachment 75571 --> https://bugs.winehq.org/attachment.cgi?id=75571 Patch to update prefix if userprofile is missing Attaching a patch to work around the issue. Although I somehow doubt that'll be accepted, it's a very fringe usecase. -- 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=55975 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |enhancement Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Fabian Maurer <dark.shadow4(a)web.de> --- Otherwise, you can just run "wineboot -u" yourself for the same effect. -- 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=55975 Alois Schlögl <alois.schloegl(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|crash if any application |crash of any application |during file-open dialog |during file-open dialog |when |when |$WINEPREFIX/drive_c/users/$ |$WINEPREFIX/drive_c/users/$ |(whoami) is renamed or does |(whoami) is renamed or does |not exist |not exist -- 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=55975 --- Comment #3 from Alois Schlögl <alois.schloegl(a)gmail.com> --- (In reply to Fabian Maurer from comment #2)
Otherwise, you can just run "wineboot -u" yourself for the same effect.
thanks for the hint, I was not aware of this. And yes, my tests show that this would be a suitable workaround. I do not know how I could have figured this out myself. In any case, a crash shouuld be considered a bug. If some state is not supported, it should be handled gracefully, showing an error message that would help identifying the issue. At first I thought the problem is with the application because it was starting but crashing only at some later time. It took quite some effort to figure out what the actually problem was. I did not test your patch, but if it fixes this issue, it would be great if it would be included in wine. -- 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=55975 --- Comment #4 from Fabian Maurer <dark.shadow4(a)web.de> --- All the patch does it force wineboot -u when the user profile is missing. Not sure how accepted this is though, Windows too will have issues if you move important folders. After codefreeze I might propose it and see what happens... -- 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