On 9/19/12 5:23 PM, Scott Ritchie wrote:
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.
I have found a better solution: you can use standard FUSE options to
mask the true owner such that it is always presented as the mounting
user, even if the file is untouched.
