Absolute Junction Points/Symlinks

Erich E. Hoover erich.e.hoover at gmail.com
Sat May 16 17:48:46 CDT 2020


I've been trying to come up with a way to solve the problem of
creating absolute symlinks inside a WINEPREFIX, since I believe this
is now the last barrier for the Junction Point/Symlink patches*.  The
current staging patch includes the prefix path in the absolute
symlink, which creates obvious problems if the prefix is ever moved to
a new location.

A proposal a while back was to use "/proc/self/cwd" as part of the
symlink and force wine to always use the prefix folder as the "real"
working directory.  This has the downside that the symlinks will break
outside of Wine, but got me thinking about other possible ways to make
the absolute symlinks work outside of Wine.  So, I put together a
small tool that builds a chroot for the prefix and creates a special
root folder "??" with bind mounts that allows symlinks to follow a
semi-NT style (e.g. '/??/C:/windows/system32' instead of
'\??\C:\windows\system32').  This technique wound up working
remarkably well, with the obvious downside that it requires additional
administrative privileges for the "launcher" app.

This idea has a logical extension to drop the need for admin rights:
use LD_PRELOAD and wrap essential path resolution functions.  While
conceptually straightforward, this is very challenging to do in
practice.  Fortunately, we are not actually trying to create a chroot
- we just need to inject a fake "??" folder at the root mount point.
After quite a bit of trial and error I've managed to put together a
"wineprefix" tool that does this correctly for both Wine and bash, a
couple interesting examples are attached (examples.txt).

I'm curious what people think about this approach.  You clearly need
to run "wineprefix" for the symlinks to be valid, but once you've done
that everything "just works".  So, what do people think?  Is this
worth turning into a tool for Wine or is it completely insane?

Best,
Erich

* sans some rebasing work that recently got introduced
-------------- next part --------------
ehoover at lappy:~$ wineprefix
ehoover at lappy:/??/C:$ ln -s '/??/C:/windows/system32/wbem' TEST && ls TEST/
mofcomp.exe  wbemdisp.dll  wbemprox.dll  wmic.exe  wmiutils.dll
ehoover at lappy:/??/C:$ ls '/??'
C:  Z:
ehoover at lappy:/??/C:$ exit
ehoover at lappy:~$ ls -haltr .wine/drive_c/TEST
lrwxrwxrwx 1 ehoover ehoover 28 Apr 30 17:16 .wine/drive_c/TEST -> '/??/C:/windows/system32/wbem'
ehoover at lappy:~$ ls -haltr .wine/drive_c/TEST/
ls: cannot access '.wine/drive_c/TEST/': No such file or directory
ehoover at lappy:~$ wineprefix wine cmd
000b:fixme:winediag:__wine_start_process Wine Staging 5.0 is a testing version containing experimental patches.
000b:fixme:winediag:__wine_start_process Please mention your exact version when filing bug reports on winehq.org.
Microsoft Windows 6.1.7601

C:\>dir /w C:\TEST
Volume in drive C has no label.
Volume Serial Number is e780-5b50

Directory of C:\TEST

[.]            [..]           mofcomp.exe    wbemdisp.dll   wbemprox.dll
wmic.exe       wmiutils.dll 
       5 files                3,056,995 bytes
       2 directories     97,899,421,696 bytes free


C:\> exit
ehoover at lappy:~$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wineprefix.c
Type: text/x-csrc
Size: 6351 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200516/3296dabc/attachment-0002.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libwineprefix.c
Type: text/x-csrc
Size: 21934 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200516/3296dabc/attachment-0003.c>


More information about the wine-devel mailing list