RFC: Sharing a wineprefix

[Paul Chitescu]

On Saturday 26 September 2009 02:19:53 Avery Pennarun wrote:
> On Fri, Sep 25, 2009 at 3:35 PM, Paul Chitescu <paulc at voip.null.ro> wrote:
> > Required changes I've identified so far:
> >        - The R/W lock to the prefix
> >        - wineserver -k as admin should terminate all users' instances
> >        - wineserver needs to be able to load Registry hives R/O
> >        - wineboot needs to be able to create just the user's profile and
> > ignore pending renames for restricted users
> >        - Report to application the detected type of user: Administrator /
> > Restricted - Some winecfg settings need to be migrated from HKCU to HKLM
> > so the admin can enforce sane values or provide proper defaults or
> > because they are logically per prefix
> >        - The user Registry hive and the temporary directory for the
> > restricted users need to be stored in their profile directory
>
> In my particular case, what I would like is in some ways actually simpler:
>
> - Define WINEPREFIX and WINEUSERPREFIX.
>
> - For all file accesses:
>  - If accessing read-only: try reading from WINEUSERPREFIX; if it's
> not there, use WINEPREFIX instead.
>  - If accessing read-write: try reading from WINEUSERPREFIX; if it's
> not there, copy from WINEPREFIX instead.
>
> If the admin updates WINEPREFIX, then I can just wipe out my personal
> WINEUSERPREFIX to see his changes.
>
> You might want to be configurable to have certain paths (the HKLM
> registry and Program Files folders, among others) not ever use the
> WINEUSERPREFIX, but I don't need that.
>
> I think this feature would be really handy for supporting shared
> installations.  One big advantage of this method over others is that
> it should work even if multiple users are doing destructive things to
> the same files; they won't see each others' changes.  This makes it
> great for test environments (which is one of the things I'd definitely
> use it for).
>
> Have fun,
>
> Avery

What you're proposing here is essentially an overlay file system.

The best would be to use a real overlay file system driver as:
- Doesn't require complex coding in Wine
- Can offer features not easy to implement like local deletion (file or 
directory exist in the main prefix but we don't want them in the "copy")
- It offers an unified view between Wine and the host operating system
- Can be tested outside Wine
- The developers of the filesystem already banged their heads against the many 
ways such an overlay system may fail.

You should also know that any such simplistic approach can fail in interesting 
and hardly to debug ways unless the user's prefix is wiped (which you already 
noted) which is unacceptable in most scenarios.

Paul