So, I believe I have a legitimate use case for ignoring this, and want
to know what sort of patch would go forward.
Imagine a distro package containing a Windows game in the form of a
read-only copy of an installed prefix (into, say, /opt). When the user
launches the app (via desktop file) this in turn launches a script that
does the following:
1) Makes a temporary folder
2) Sets up a unionfs-fuse copy-on-write mount between ~/.appname and the
read-only packaged prefix in /opt, mounted in the temporary folder
3) Runs the app with WINEPREFIX= the temp folder
4) When the app is finished, unmounts the temp folder
This all works quite fine: new (or modified) files within the prefix get
stored in ~/.appname, to be restored the next time the user runs the
app. Distinct users can run the app simultaneously, as they each have
their own prefix. Excess file-copying is avoided, as only the
user-modified files need to be stored in the home folders.
There is one major snag, however: unionfs displays the owner as root
until the user has modified/copied it. This means Wine refuses to
launch as the user with the "root-owned" prefix. Simply commenting out
this part of the code makes Wine work fine, however I'd like to be able
to have a proper solution.
Would something like a command-line switch or environment variable be
acceptable here?
Thanks,
Scott Ritchie
* 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, but
that's a different feature request
