Overriding the check for ownership of a prefix

[Scott Ritchie]

On 9/24/12 2:48 AM, Joerg-Cyril.Hoehle at t-systems.com wrote:
> Scott,
>
> I don't think you need to override this check, esp. given that
> there's a good reason for it being there:

The good reason doesn't apply in this use case.  Overriding it fixes 
every problem I'm facing without having to do anything complicated or 
manual.

>> Note that there is a problem with this setup if the app modifies
>> the registry and we then need to update the prefix-default
>> registry
>
> I've excellent experience with symbolic links. In fact, none of the
> apps (games) I use are installed directly within any .wine prefix.
> Drive_c/Program Files/Games is a symbolic link to a large partition.
>

Your apps don't need to have conflicting registry settings then.  I
can't assume I'll always be so lucky.

>> Imagine a distro package containing a Windows game in the form of
>> a read-only copy of an installed prefix (into, say, /opt).
>
> So I recommend the following setup: - Have the game's main directory
> be something like /opt/games/XYZ in UNIX, but tell it to install to
> C:\games/XYZ - During installation, write down all registry keys that
> the app creates and every file that it stores outside of its local
> directory.
>
> Beware: the name of the directory C:\Program.. depends upon every
> user's locale at .wine creation time! Use C:\Games\ instead to avoid
> that pitfall.
>
> For every user: - After .wine is created normally, add a symlink
> from Drive_c/Games to /opt/games - Add registry keys or dlls needed
> by the app.
>
> wineprefixcreate ln -s /opt/games/XYZ $HOME/.wine/drive_c/games cp -p
> whatever.dll $HOME/.wine/drive_c/windows/system32/ wine regedit
> xyz.reg
>
> Trivial, isn't it?
>

We can't assume apps will install cleanly, or only need the files in
their install directories; copying to windows system folder does happen,
and then it becomes a real mess.

> Typically, you don't need to recreate the content of user-local
> APPDATA directories. The app will create them upon each run, since
> they ought to run with different users on one machine.
>
> Caveat: Although my .wine and games directories are distinct, I've no
> experience with write-protecting the games partition.  Obviously,
> this only has a chance to work with modern apps, written after MS
> started recommending separating the app's dir from its per-local
> configuration files to be since stored in ~/LOCALAPPDATA or the like.
> Thus w9x/w2k-era games are ruled out.  Still, I don't know where
> those apps attempt to store e.g. crash logs.
>
> I've seen apps write high-scores or savegames to their central
> directory when w2k was set in winecfg, and use HKCU/LOCALAPPDATA
> (what's the exact name?) when running in xp mode.
>
> I've made excellent experience with plenty of apps sharing a single
> .wine-games prefix with such a setup.  I.e. you don't need one prefix
> per app.  Like on a real box, the apps ought to be able to coexist.
>

Perhaps.  But separate prefixes give us so many advantages here, at the 
mere cost of some disk space.

> Drawback: when I was initially attracted to Wine 5 years ago, every
> .wine was a tiny 3-4MB. Nowadays it's more than 10 times that size,
> and I'm not happy with that. Using a single onion-union-fs to share
> drive_c/xyz may be interesting -- for as long as one single version
> of Wine is in use.
>
> Regards, Jörg Höhle
>

Thank you though, you do propose one alternative.