WINE File Duplication
In our our migration effort we are using WINE. Currently the sole reason is to run the Mikrotik Winbox program.
Cynical side comment: The Mikrotik folks make a boat load of money using the Linux kernel as the foundation for their business. Yet they refuse to create a nice cross-platform app.
We have no problems running Winbox in WINE. Yet I did not like how WINE is designed. There is significant duplication of files in a multi-user environment.
The WINE FAQ indicates that a common install directory is not well supported. Instead WINE is expected to be installed separately for each unique user account. In our use case I noticed each user’s
~/.wine directory pushing about 800 MB. The duplicated storage space accumulates fast on a multi-user system, especially on smaller SSDs.
I dug into this issue to find the file bloat.
We are using the upstream stable 3.0.3 version of WINE and not the older package provided in the Ubuntu repos. This contributes to the file bloat.
When first run, WINE asks the user to install a Mono and two Gecko packages. When the user downloads the upstream
*.msi packages the files are stored in two places: 1)
~/.cache/.wine and 2)
After installation the
*.msi packages are not deleted in either directory. If newer versions are installed then the
*.msi files accumulate in both directories.
In a test system I deleted the
~/.wine directory and launched WINE. I canceled the WINE requests to install the three
*.msi packages. The resulting
~/.wine directory is about 43 MB. Far more palatable than pushing almost 1 GB.
~/.wine and running fresh, installing the requested
*.msi packages increases the size of
~/.wine to 538 MB. The three
*.msi packages consume 150 MB. Deleting the
*.msi files reduces
~/.wine to 388 MB.
One caveat with starting fresh is
~/.wine is not reduced in size because the
*.msi files are cached in
~/.cache/.wine. Thus each fresh run of WINE will immediately install the three
*.msi packages. Sneaky bloat. Delete the cached
*.msi files if starting fresh and wanting to minimize the bloat.
Digging deeper, Ubuntu provides a
wine-gecko package. Without investigating, seemingly installing those packages should address the duplication problem. Not really. The deb packages are merely wrappers to the
*.msi files. If found WINE uses those
*.msi files to install rather than download from upstream.
In our use case the stable 3.0.3 package from the WINE repos does not recognize the Ubuntu/Debian packages. Or possibly refuses to use the
*.msi files because of version discrepancies. Hence the request to install the WINE repo version of those packages.
Unfortunately in any case, those
*.msi packages get installed locally to each user’s
~/.wine directory. The result is duplication and bloat when a system supports multiple users.
Duplication exists with 1) the
*.msi files being installed in
/usr/share/wine when using the distro repos, 2) being installed in each user’s
~/.wine/drive_c/windows/Installer and 3)
A more efficient solution would be unpacking the
*.msi files in
/usr/share/wine rather than just provide a wrapper and symlinking the files in each user’s
~/.wine. I see no reason why the files must be installed locally in each user’s
Although a fresh
~/.wine directory is about 43M, there remains much duplication across multiple users with the
*.dll files. Again, installing those files once in
/usr/share/wine and using symlinks would be more efficient.
Or instead of symlinks, WINE should be designed to look for those files in
/usr/share/wine. That seems feasible because WINE is already designed to look in
/usr/share/wine for the
As a workaround I don’t know how much success a sysadmin would have trying to shoehorn WINE with symlinks.
Remarkable reverse engineering but WINE has always felt like walking with a pebble in the shoe.