[Bug 11112] New: Does the fatal error if the config directory isn' t owned by the user make sense?
http://bugs.winehq.org/show_bug.cgi?id=11112
Summary: Does the fatal error if the config directory isn't owned by the user make sense? Product: Wine Version: CVS/GIT Platform: All OS/Version: All Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: bero@arklinux.org
Created an attachment (id=10147) --> (http://bugs.winehq.org/attachment.cgi?id=10147) Proposed fix
Recent wine versions abort on startup if the config directory isn't owned by the user running wine.
This breaks setups where several users share a common wine prefix (e.g. to make applications that make heavy use of the registry available to several users without installing them several times) and they have the right access to the configs through group permissions.
Unless I'm overlooking a better way to do this, it would make more sense to check proper permissions than to check ownership. I'm attaching a patch that does that.
http://bugs.winehq.org/show_bug.cgi?id=11112
Yolande Haneder yolande@haneder.biz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yolande@haneder.biz
--- Comment #1 from Yolande Haneder yolande@haneder.biz 2008-01-10 03:24:29 --- I will test your fix and send you a feedback straight away.
I have an application affected by this.
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #2 from Yolande Haneder yolande@haneder.biz 2008-01-10 03:33:25 --- (In reply to comment #1)
I will test your fix and send you a feedback straight away.
I have an application affected by this.
Just to enlighten some, the .NET is taking the config file from Linux (yes, I have seen it!!!) and I have seen through a regression test that the changed here patched affected me.
http://bugs.winehq.org/show_bug.cgi?id=11112
L. Rahyen mail@science.su changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mail@science.su
--- Comment #3 from L. Rahyen mail@science.su 2008-01-10 03:54:08 --- Yes, this is good idea!
Your solution looks cleaner and smarter than what is currently implemented in WINE.
Personally I currently is forced to use a hack to remove this useless (in my case) check. I have a good reason for that - reconfiguring dozens of WINE prefixes for a lot of users isn't an option (and WINE even don't provide standard way to (re)configure for multiuser setup). Your patch fixes this problem and creating multiuser setup with WINE (and your patch applied) is as simple as creating multiuser setup with any other Linux application.
You need to send your patch to wine-patches mailing list. It is recommended to subscribe to the mailing list before sending (you can do this here: http://www.winehq.org/mailman/listinfo/wine-patches ). Thanks.
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #4 from Yolande Haneder yolande@haneder.biz 2008-01-10 03:57:35 ---
From my side *Thank you*.
This seems to clear bug 10584 (tested on SDLX which was affected and untouched by my previous tests --> ending with "setup exception" and not "setup error" (setup error was the error for the regression test).
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #5 from Alexandre Julliard julliard@winehq.org 2008-01-10 05:01:59 --- (In reply to comment #0)
Unless I'm overlooking a better way to do this, it would make more sense to check proper permissions than to check ownership. I'm attaching a patch that does that.
No, the whole point of the patch is precisely to prevent separate wineserver instances from trying to write to the same registry files, since that doesn't work.
http://bugs.winehq.org/show_bug.cgi?id=11112
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX
--- Comment #6 from Vitaliy Margolen vitaliy@kievinfo.com 2008-01-10 10:00:31 --- This is by design, as Alexandre said. Wine should not start when run as a different user with some one else's configuration. There are lots of "smart" users doing "sudo wine <blah>". This is what this check protects against. If you do not like it - have each user copy Wine config.
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #7 from Yolande Haneder yolande@haneder.biz 2008-01-10 11:20:55 --- Dear Vitality,
I know you don't like issues about the .NET. However if the installshield is scanning the whole disk instead of just the wine prefix and installs some installation temporary files in the linux temp file which by definition belongs to root. Now I have at least 20 files as per the attachment (some different kind of), they are all stored in the temp directory which is owned by root. The rights are owned by me, in an directory owned by root but I can't access them because the .NET did change the rights of them.
How do I solve this mess using sudo? Is there not a way of keeping Wine inside its boundaries then if it's not allowed to go into directories owned by root?
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #8 from Yolande Haneder yolande@haneder.biz 2008-01-10 11:31:49 --- Dear Vitality,
Now I have a question for you: If I look into the wine directory, there is c: and z:. Unfortunately I have many temp files ending in z:\temp (java classes or OLE files that I can't access even if I am the owner because the .NET reverted the rights). Now the z: does belong to root and there is thus no way that wine can access to the z: because c: is yolande and z: is root. How do you solve that then? Do you have a sudo for z: in the middle of an installation procedure (please note that z:\temp does also belong to root).
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #9 from Bernhard Rosenkraenzer bero@arklinux.org 2008-01-10 11:35:57 --- The intent of the original patch is to allow a setup where several users, let's call them "mom" and "dad", can share their Windoze applications without using the same account. Assuming the users are non-technical, it is safe to assume that they won't know how to copy registries around every time they install a new application, and it's also safe to assume that they won't be using the computer at the same time (at least not with different accounts) -- this is a pretty common situation and IMO should be addressed in some way.
Of course it also opens the possibility to mess up by running wine something.exe and sudo wine something.exe simultaneously - maybe the best way to stop that is creating a lock file in the config directory that is writable by the user only, and if it's there and owned by another user, abort with an error message saying "dad is currently using wine, please wait until he is done or create a separate wineprefix using wineprefixcreate"?
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #10 from Yolande Haneder yolande@haneder.biz 2008-01-10 11:53:11 --- Created an attachment (id=10156) --> (http://bugs.winehq.org/attachment.cgi?id=10156) One of the things that I get from Wine into z:
Not being able to save such a file in the temp directory (owned by root) is causing the installation to abort with a setup error.
http://bugs.winehq.org/show_bug.cgi?id=11112
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|WONTFIX |
--- Comment #11 from Alexandre Julliard julliard@winehq.org 2008-01-10 12:09:22 --- Temp files should go under c: somewhere, if they go in z:\temp there's something wrong with your setup. In any case it's unrelated to this bug.
Still, the actual problem that my hack was fixing could be fixed a better way, so this bug should remain open.
http://bugs.winehq.org/show_bug.cgi?id=11112
Marco Schuster marco@harddisk.is-a-geek.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marco@harddisk.is-a-geek.org
--- Comment #12 from Marco Schuster marco@harddisk.is-a-geek.org 2008-01-10 12:14:35 --- @Vitaliy: For those "smart" users running wine through sudo, I have written a patch which was rejected - maybe it gets its revival here.
Or there should be some kind of configuration option to disable the owner-check, I think of winecfg here.
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #13 from Austin English austinenglish@gmail.com 2008-01-10 12:24:58 --- Do we want to support multiple users sharing the same prefix? I haven't seen too much about this lately, though I know in the past you could share a drive c, dosdevices and system.reg, but that the user.reg and userdef.reg had to be unique to the user. Is that still the case? If so, we could only check that user/userdef.reg are user owned/writable, but on the others, check that we have the correct permission, not ownership.
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #14 from Vitaliy Margolen vitaliy@kievinfo.com 2008-01-10 13:27:25 --- (In reply to comment #8)
Dear Vitality,
Now I have a question for you: If I look into the wine directory, there is c: and z:. Unfortunately I have many temp files ending in z:\temp (java classes or OLE files that I can't access even if I am the owner because the .NET reverted the rights). Now the z: does belong to root and there is thus no way that wine can access to the z: because c: is yolande and z: is root. How do you solve that then? Do you have a sudo for z: in the middle of an installation procedure (please note that z:\temp does also belong to root).
rm -rf ~/.wine Clearly it's screwed up. Don't f** with something you have no concepts about. Still don't see a bug here. So far you've been talking about how badly you managed to break your setup.
(In reply to comment #12)
@Vitaliy: For those "smart" users running wine through sudo, I have written a patch which was rejected - maybe it gets its revival here.
Ask Julliard, not me.
(In reply to comment #11)
Temp files should go under c: somewhere, if they go in z:\temp there's something wrong with your setup. In any case it's unrelated to this bug.
Still, the actual problem that my hack was fixing could be fixed a better way, so this bug should remain open.
Hack what hack? I thought those not allowed in.
(In reply to comment #13)
Do we want to support multiple users sharing the same prefix? I haven't seen too much about this lately, though I know in the past you could share a drive c, dosdevices and system.reg, but that the user.reg and userdef.reg had to be unique to the user. Is that still the case? If so, we could only check that user/userdef.reg are user owned/writable, but on the others, check that we have the correct permission, not ownership.
No, this can not be supported. Wineserver does not sync with registry on the disk. It only writes there on exit or periodically (if configured). So you'll loose someone's changes.
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #15 from Yolande Haneder yolande@haneder.biz 2008-01-10 23:32:53 --- I have deleted the wine prefix at least 30 times this week!!!
Don't tell me it is enough just to delete the wine prefix! I have even reinstalled the whole Linux and the temp are going there again and again. At the most it is because the net is taking the .config file of linux and reading amongst others that the temp is here!
If you know somebody from Austria (around Vienna) he/she is free to come and delete my prefix 100 times, it will be installed 100 times again there (provided you empty the cache every time).
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #16 from L. Rahyen mail@science.su 2008-01-11 01:08:19 --- Yolande Haneder, please open a separate bug report if you *really* think that a problem you found is a bug in WINE. But it is unrelated to this bug report. This bug report is about a problem with multiuser setup, and only one problem per bug is allowed.
---
I think that should be a registry switch (somewhere in Software\Wine registry branch) and a command-line option to disable this check. This will solve all problems. For example:
wine --disable-owner-check notepad
Or (short switch):
wine -d notepad
Having ability to disable unnecessary checks is the standard in the Linux World. Especially this is true for checks that are exist only as protection from newbie users (or users who don't understand what he/she is doing). Expert users should be able to do what they want to do.
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #17 from Yolande Haneder yolande@haneder.biz 2008-01-11 01:25:40 --- Dear L.
I do understand your point. I just came to this bug because as I wrote my first message, the second was not there and I was happy that someone else came to the conclusion that this check was creating problem.
I will not open a bug because I already have one about the setup error which ended with a regression test and my trying to understand what it had to do with me. Since then I reverted the commmit once, got my tmp files and the problem is bypassed.
I just would like that Vitality one day understand that I am not doing anything outside the rules when talking about a .NET problem because he can't reproduce it. I can reproduce it and I think it might work on red hat, solaris and mac as well as from sled (for the others I am not sure). I can get a foreign notebook with sled and install it there too. There is nothing about specific settings or that I corrupted anything.
I won't add anything anymore - promised!
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #18 from Alexandre Julliard julliard@winehq.org 2008-01-11 04:40:50 --- (In reply to comment #16)
I think that should be a registry switch (somewhere in Software\Wine registry branch) and a command-line option to disable this check. This will solve all problems. For example:
wine --disable-owner-check notepad
Or (short switch):
wine -d notepad
Having ability to disable unnecessary checks is the standard in the Linux World. Especially this is true for checks that are exist only as protection from newbie users (or users who don't understand what he/she is doing). Expert users should be able to do what they want to do.
The check can be disabled by creating a temporary wineprefix dir that contains symlinks to the real files. For an expert user that's surely not harder than specifying a command line option.
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #19 from L. Rahyen mail@science.su 2008-01-11 06:17:01 ---
The check can be disabled by creating a temporary wineprefix dir that contains symlinks to the real files. For an expert user that's surely not harder than specifying a command line option.
I know that and I even recommended doing this on wine-users mailing list some time ago as possible solution for this problem.
However what if I'm creating new WINE prefixes frequently? For example, new prefix for new set of Windows programs (sometimes there is good technical reasons for doing this, especially in multiuser setup). I need then to write a script to bypass this check and launch it for each new WINE prefix. Yes, I can do that (in fact, I'm professional Linux programmer - in other words, this is my occupation). But fixing the problem in WINE source is not only faster but more convenient (because there is no need to write a wrapper script for wineprefixcreate; and I'm recompiling WINE git tree after each update anyway).
I see no harm in adding at least command-line switch (this is very easy to implement because interaction with registry isn't required). In fact, this is traditional practice. User who didn't read the documentation will not be able to bypass the check. And user who did read the documentation (or was instructed by an expert) will be able to do what he/she want to do - without spending time for writing wrapper script or modifying the source code.
By the way, not all users who need multiuser setup are programmers. But most users can easily add an alias or command-line switch. This is especially important when helping a user to create working multiuser setup with WINE. I can easily explain how to add command-line switch (and what problems might happen because of its use) or create an alias but explaining how to create symlinks for each user is much more harder (at least that's my real-life experience). This is why I care about this problem.
My final question is: can I expect a patch adding such command-line option to be accepted?
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #20 from Alexandre Julliard julliard@winehq.org 2008-01-11 08:02:37 --- (In reply to comment #19)
My final question is: can I expect a patch adding such command-line option to be accepted?
No. I agree with you that it would be nice to make it easier to create robust multi-user setups, but the way to do that is not to provide an option to bypass the security check. The check is here because it's currently not possible to make multiple users share a wineprefix reliably; playing with permissions is certainly not enough, sooner or later you'll get a corrupted registry.
What needs to be done is to fix the code so that the multiple servers case is detected and handled correctly. Once this is done the check can be removed.
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #21 from L. Rahyen mail@science.su 2008-01-11 09:39:54 --- Thank you for explanation.
What needs to be done is to fix the code so that the multiple servers case is detected and handled correctly. Once this is done the check can be removed.
OK, I agree, this would be better solution.
Then this bug is about lack of proper support for multiple wineservers running simultaneously. Can someone change the bug summary to something more appropriate? For example, "Running multiple wineservers simultaneously can corrupt registry".
http://bugs.winehq.org/show_bug.cgi?id=11112
Luke Bratch l_bratch@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |l_bratch@yahoo.co.uk
http://bugs.winehq.org/show_bug.cgi?id=11112
--- Comment #22 from L. Rahyen mail@science.su 2008-04-12 00:27:56 --- Perhaps this bug should be nominated for 1.2?
http://bugs.winehq.org/show_bug.cgi?id=11112
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Does the fatal error if the |Running multiple wineservers |config directory isn't owned|simultaneously can corrupt |by the user make sense? |registry Target Milestone|--- |1.2.0
http://bugs.winehq.org/show_bug.cgi?id=11112
Tefnet developers developers@tefnet.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #23 from Tefnet developers developers@tefnet.pl 2008-04-13 03:56:00 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=11112
Tefnet developers developers@tefnet.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |developers@tefnet.pl
http://bugs.winehq.org/show_bug.cgi?id=11112
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11112
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|CVS/GIT |unspecified
--- Comment #24 from Austin English austinenglish@gmail.com 2009-01-18 03:47:33 --- Removing deprecated CVS/GIT version tag. Please retest in current git. If the bug is still present in today's wine, but was not present in some earlier version of wine, please update version field to earliest known version of wine that had the bug. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=11112
nathan.n saturn_systems@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |saturn_systems@yahoo.com
http://bugs.winehq.org/show_bug.cgi?id=11112
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OS/Version|All |other Platform|All |Other
http://bugs.winehq.org/show_bug.cgi?id=11112
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kennybobs@o2.co.uk
http://bugs.winehq.org/show_bug.cgi?id=11112
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com Target Milestone|1.2.0 |---
--- Comment #25 from Dan Kegel dank@kegel.com 2009-11-01 07:31:26 --- Supporting multiple wineservers on same prefix doesn't seem like a 1.2 kind of bug to me.
http://bugs.winehq.org/show_bug.cgi?id=11112
Reco recoverym4n@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |recoverym4n@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11112
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Eldmannen+wine@gmail.com
--- Comment #26 from Austin English austinenglish@gmail.com 2010-04-17 13:05:00 --- *** Bug 22388 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=11112
Rickard Närström rickard.narstrom@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rickard.narstrom@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11112
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |c.trapt@gmail.com
--- Comment #27 from Rosanne DiMesio dimesio@earthlink.net 2010-06-06 09:15:21 --- *** Bug 23053 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=11112
Peter torre_cremata@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |torre_cremata@mail.ru
http://bugs.winehq.org/show_bug.cgi?id=11112
fracting fracting@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fracting@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=11112
Peter Quiring pquiring@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pquiring@gmail.com
--- Comment #28 from Peter Quiring pquiring@gmail.com 2011-12-08 10:39:25 CST --- One way this could get fixed is if wineserver was overhauled a little to delay loading the HKCU registry key until each client connects. The HKCU key would be attached to each connection instead of being global. As the wine client connects it would first announce the username/sid and then wineserver could load the user.reg file from the users .wine folder. This means that wineserver would have to run as root to load other users files like a system service. wineserver -s, --service multi-user service
http://bugs.winehq.org/show_bug.cgi?id=11112
Paul Chitescu paulc@voip.null.ro changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |paulc@voip.null.ro
--- Comment #29 from Paul Chitescu paulc@voip.null.ro 2012-02-08 12:12:52 CST --- (In reply to comment #28)
One way this could get fixed is if wineserver was overhauled a little to delay loading the HKCU registry key until each client connects. The HKCU key would be attached to each connection instead of being global. As the wine client connects it would first announce the username/sid and then wineserver could load the user.reg file from the users .wine folder. This means that wineserver would have to run as root to load other users files like a system service. wineserver -s, --service multi-user service
Running wineserver as root is a very complex problem by itself. It would mean that wineserver would need to reimplement many of the access rights normally provided by the operating system. The security implications are mindblowing.
Maybe we should focus on a slightly different problem that seems easier to implement since it doesn't seem that simultaneous access from different users is needed.
We could have a setuid wrapper that performs the equivalent of chown -R user once it locked the wineprefix and then switches back to the original user. This way the access rights will be correct.
A helpful touch would be to move user.reg inside c:\users%USERNAME% so each user will have its own HKCU.
http://bugs.winehq.org/show_bug.cgi?id=11112
oiaohm oiaohm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oiaohm@gmail.com
--- Comment #30 from oiaohm oiaohm@gmail.com 2012-03-18 04:32:50 CDT --- Lets see if we can avoid this hell.
Remember current wine default is admin level user.
Can we enable limited usermode. This means that system hive become read only. Of course user hives remain read write.
Directory layouts as I dream them. /opt/shared-application/ system.reg drive_c/ dosdevices/ userdef.reg user.reg limited.ver
~/.wine limited->/opt/shared-application/ dosdevices/ userdef.reg user.reg profile/ limited.ver
So drive_c and system.reg are read only to everyone accept admin. limited.ver contains a number that is increased when shared-application is edited.
Key thing here is we don't need a global wineserver to make this work. We don't need to be changing permissions all the time.
We just need a per user wineserver that can cope with the fact that system.reg is read only and drive_c is read only. Due to version tag alterations to read only drive_c could be recorded temp in user profiles and cleared when version increases.
Limited user mode would allow some applications to be run shared. Not all applications expect to write into there application directories and the like.
http://bugs.winehq.org/show_bug.cgi?id=11112
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sworddragon2@aol.com
--- Comment #31 from Austin English austinenglish@gmail.com 2012-06-26 13:37:22 CDT --- *** Bug 31026 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=11112
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source Component|-unknown |wineserver Platform|Other |x86 Version|unspecified |0.9.53. OS/Version|other |Linux
http://bugs.winehq.org/show_bug.cgi?id=11112
Hans Deragon hans@deragon.biz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@deragon.biz
https://bugs.winehq.org/show_bug.cgi?id=11112
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=17337
https://bugs.winehq.org/show_bug.cgi?id=11112
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=30647
https://bugs.winehq.org/show_bug.cgi?id=11112
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |la_iscla@mac.com
--- Comment #32 from Austin English austinenglish@gmail.com --- *** Bug 45164 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=11112
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=11112
N acroq3@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |acroq3@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=11112
Vitaly Lipatov lav@etersoft.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lav@etersoft.ru
-
wine-bugs＠winehq.org -
WineHQ Bugzilla