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
On Wed, 19 Sep 2012, Scott Ritchie wrote: [...]
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.
Wine checks the ownership of the $WINEPREFIX directory right? So wouldn't touching a file in $WINEPREFIX before starting Wine work? system.reg would be a good candidate. Alternatively, create/delete some other file.
On 9/20/12 3:07 AM, Francois Gouget wrote:
On Wed, 19 Sep 2012, Scott Ritchie wrote: [...]
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.
Wine checks the ownership of the $WINEPREFIX directory right? So wouldn't touching a file in $WINEPREFIX before starting Wine work? system.reg would be a good candidate. Alternatively, create/delete some other file.
Yes, unfortunately unionfs displays a sort of mixed permission structure: files are owned by the user once they are modified, but the hosting directory name itself can't be modified in this way, which is exactly what Wine checks.
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.
-
Francois Gouget -
Scott Ritchie