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:
- Makes a temporary folder
- 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.