Request for patch removal

Steve Brown sbrown7 at
Wed Jan 16 10:01:55 CST 2008

On Wed, 16 Jan 2008, Dmitry Timoshkov wrote:

> "Federico Vecchiarelli" <fedev at> wrote:
>> Ok, to the point. The patch mentioned below prohibits wine from running
>> any application which is inside someone else's folder, even if you have
>> access to it. In my case, I wanted to make one unique installation
>> available to several users. Because of this patch, there is no
>> workaround that could be implemented, forcing me to either run a script
>> changing the owner of the folders for every user as they want to use the
>> application or I have to make several copies of the software which will
>> put me in a difficult legal situation.
> All the details about this problem you can find here:
> -- 
> Dmitry.

Allow me to add my voice on this subject.  I also would like the Wine 
developers to consider how to allow for this use case.  In a centrally 
administered environment, most users do not have write access to much of 
the local disk, and the administrator of the machine (root) sets up the 
environment for them (and normal users should not be allowed to muck with 
it).  I am administrator for a small group of folks here, and would switch 
to Linux only -- but there are still Windows-only programs that are 
critical for my users.  Wine would be a wonderful solution, if only wine 
could be installed in a central location (say, /usr/local) and the wine 
"registry" files could be shared, somehow, by all users on the machine 
(maybe by doing a union of ~/.wine and /usr/local/wine/whatever).

I see in the comments on this bug, that the concern is with multiple 
instances of wineserver running on the machine at one time -- that's not a 
major issue in the use case I envision.  The multiple wineservers would 
not be running at the same time (unless the install is on what Windows 
would call a Terminal Services Server -- a normal multi-user *nix 
machine).  I think that even just allowing for multiple login users on a 
local machine at different times would be sufficient for a lot of us.  If, 
say, ~/.wine was used as a replacement for HKLM\Current User and, say, 
/usr/local/wine/whatever was for the other registry hives and group 
policies, I think wine would be a lot closer to being a solution for those 
of us maintaining multi-user machines.

Steve Brown
Systems Administrator
UMBC Imaging Research Center
sbrown7 at

More information about the wine-devel mailing list