A bind mount, like any other mount, covers an existing directory, thereby making the underlying contents invisible/inaccessible to processes accessing that information. In this case, it means I don't have to delete or rename the save directory -- I just copy it to another location and then bind mount that new location over the existing directory, creating a temporary replacement.

When I remove the mount, if I don't want to keep the changes that have been made, there's nothing left to do -- it's already effectively reverted to its previous state. If I do want to keep them, I just rsync the changes back to their original location.

You most commonly see bind mounts and recursive bind mounts used for setting up chroot environments (/proc, /sys, and /dev).

Combining bind mounts and union filesystems (like aufs or overlayfs) allows for artificial write access to an intended read-only environment -- like a mounted squashfs image, but it can really be anything you don't want to unintentionally modify. When you throw in ramdisks you're basically giving yourself a high-speed scratch disk for test work. If you decide to keep some of the changes, you can always copy them back to the original source, or an overlaid source, at a later point.

Anyway, if you're interested in playing around with it, you can do it the traditional way (mount -o bind /src /dst -or- mount --bind /src /dst) which requires sudo/root access or you can use something like bindfs which works via FUSE in user-space.

There's also proot, which features, in addition to faking bind mounts, the ability to fake some other things that normally root privileges, like chroot; it's even possible to enter an ARM chroot on an x86 system with some help from qemu-user! (That last point can, for example, be useful if your Raspberry Pi isn't booting and you want to chroot into it to fix the installation, or if you want to update the software to remove vulnerabilities without having to connect the live Pi to a networ, for example. In reverse, it might even allow running x86 games on a Raspberry Pi! (Just be prepared for poor performance; I should still try running Avernum 1 on one of these things.))

Some advantages of bind mounts instead of symlinks:
* Neither filesystem needs to support them; you can bind mount a directory from an ext4 filesystem onto a fat32 directory tree.
* You can bind mount into a read-only filesystem. For example, you can have a read-only root and a single writable filesystem, then bind mount parts of the writable filesystem into directories that need to be writable.
* You can bind mount into what systemd calls the "API filesystems" (that is, /proc, /sys, /dev); this can let you hide things, or even virtualize things (for example, faking views of certain things in /proc).
* Bind mounts work across chroot boundary; you can have a chroot for testing things, or for compatibility purposes, but still have access to your home directory on the host. This can also be used to give a chroot access to the running X server (useful if you're running something like WINE or a video game in the chroot). (This doesn't work with symbolic links since they just contain a path; chroots change the meaning of paths, so you can't symlink out of one and expect it to still point out when accessed within the chroot. A hard link would work, but you can't hard link across different filesystems.)
* When combined with mount namespaces, bind mounts can be used to give different processes different views of the filesystem. It's possible to bind mount in a mount namespace, and the bind mount won't be visible outside the namespace.

(There *are* disadvantages, however; the bind mount needs to be setup every boot (though for some uses that's actually a good thing), and superuser privileges (or at least superuser in a user namespace) are needed to perform a bind mount.)

If you have any other questions, feel free to ask; I enjoy talking about this stuff!

I forgot to mention:

Reventure runs great with basic current WINE, but it doesn't accept any input anymore after either alt-tab or changing to full-screen, but it keeps the full-screen option when set, so just shutting the game down with alt+F4 and restarting it is not a problem.
I finished the game without any further problems (and it's great btw).

Does "Chook & Sosig: Walk the Plank" run in Wine?

https://www.gog.com/game/chook_sosig_walk_the_plank

Game: Pilot Brothers 2
Version: 2.0.0.2
Installer MD5: 78026194d9ee70c21696b3d67371eae4 setup_pilot_brothers2_2.0.0.2.exe

Distro: Linux Mint 19.1 Tessa | Mate | 64-bit
Kernel version: 4.15.0-72-generic x86_64
Graphics card: Intel HD Graphics
Wine version(s) tested: Wine 5.00-rc3 32-bit
WineHQ AppDB link: no entry for this game

Install notes: Installs correctly. 4 traditional pop-up runtime errors' messages end the installation process, but with no further impact.
How well does it run: Perfect. No issues and well performance. The game has been completed.
Details: I'm using budget laptop with Intel Pentium CPU 3550M 2×2.30GHz + integrated Intel HD Graphics on board. I'm using PlayOnLinux (without their predefined scripts).

Has anyone tried Astrox Imperium by chance? If not, I was thinking about giving it a go.

Edit: Looking through the Steam discussions and Discord chat, sounds like it was working with Proton a while back. Maybe I'll give it a whirl tomorrow if I can find the time.

Game: Sacred 2 Gold
Version: 2.65.1 (32-bit)
Installer MD5:
24d0bd64c35b76eb6e72a2ff6f83b6d1 setup_sacred_2_gold_2.65.1_(18565).exe
204b2a17e939cd3d89b7bfba68f6e127 setup_sacred_2_gold_2.65.1_(18565)-1.bin
f772d8244964365683f78da968ddc7e4 setup_sacred_2_gold_2.65.1_(18565)-2.bin
2a7356d130c1b09de01e269bf30db38b setup_sacred_2_gold_2.65.1_(18565)-3.bin
1c7b60dd8038ecd4931c049155bcfa71 setup_sacred_2_gold_2.65.1_(18565)-4.bin
WineHQ AppDB Link: 2.65.2 + Community Patch (most recent, closest available version)

Distro: Linux Mint 19.2 Tina | Cinnamon | 64-bit
Kernel: 4.15.0-74-generic
Graphics: NVidia GeForce GTX 670
CPU: Intel i7-3930K @ 3.20GHz × 6
Wine Version: Wine Staging 5.0-rc5 64-bit

Install Notes:
winetricks d3dx9_36 physx
Skip/Cancel the packaged PhysX installer.
Usual 4 popups at end of installer.

How does it run:
1) Generally runs well enough, though the framerates are a little low at times.
2) Game plays smoothly with all graphics maxed, vsync, and weather enabled (Anti-Aliasing disabled).
3) The game played fine with "PhysX Effects" enabled, but sometimes crashed when returning to main screen via "Save and Exit" -- at least the save completes before crashing to desktop.
4) Every once in a while during testing, menu backgrounds would disappear completely, buttons remained clickable.
• Only encountered in fullscreen.
• Updating any graphics settings triggers a refresh and made the problem goes away.

Details:
1) Tested with Windows 7 compatibility.
2) Tested both 32 and 64 bit prefixes (performed the same).
3) Winetricks:
• d3dx9_36 - Gets around the HLSL shader issue (d3dcompiler_43 had no effect)
• physx - The pre-packaged PhysX installer didn't work -- game crashed during load
4) Anti-Aliasing should remain disabled:
• 2x makes the game stutter and caused occasional lockups
• 4x leads to a black screen
5) I kept PhysX Effects enabled for the first 30 min or so of gameplay with no notable issues (other than the "Save and Quit" crash). Playing with PhysX Effects disabled led to no issues.

Game: Pilot Brothers 3
Version: 2.0.0.3
Installer MD5: ee205b92059961b7b4b9eca244b16e3a setup_pilot_brothers3_2.0.0.3.exe

Distro: Linux Mint 19.1 Tessa | Mate | 64-bit
Kernel version: 4.15.0-72-generic x86_64
Graphics card: Intel HD Graphics
Wine version(s) tested: Wine 5.00-rc3 32-bit
WineHQ AppDB link: no entry for this game

Install notes: Installs correctly. 4 traditional pop-up runtime errors' messages end the installation process, but with no further impact.
How well does it run: Perfect. No issues and well performance. The game has been completed.
Details: I'm using budget laptop with Intel Pentium CPU 3550M 2×2.30GHz + integrated Intel HD Graphics on board. I'm using PlayOnLinux (without their predefined scripts).

Game: Wizardry: Labyrinth of Lost Souls
Version: 1.0.5 (initial release)
Installer MD5: 06a181abfc4cda79585010c253adab36
WiheHQ AppDB Link: None (game was *just* released)

Distro: Debian GNU/Linux, some combination of Stretch (9) and Buster (10)
Kernel: Linux debian 4.8.0-2-amd64 #1 SMP Debian 4.8.11-1 (2016-12-02) x86_64 GNU/Linux
Graphics: Intel HD 4600 series
CPU: Intel i5 4670, underclocked to 1.7GHz (normally speced at 3.4GHz)
Wine version: wine-4.0 (Debian 4.0-2)

Install Notes:
Installs without issue
According to winetricks, mfc42 is installed in this prefix, but that might not be necessary
Have not tried the Growth Fruit DLC

How does it run:
From what I have tried, the game runs fine. I was able to get far enough to have my character die (as this was a quick test). Does make this particular computer, which has problems, overheat a little, but that is probably not the game's fault (though it's possible this might be one of the games that wastes CPU/GPU resources and uses more electricity than it needs).

Details:
Only did a quick test of the game, but at least it worked so far.

Edit: Tried the game on my laptop, whiere the wine prefix doesn't have mfc42, but does have dxvk and direct3d 11 (don't remember the exact winetricks name). Also, one minor issue; the Acquire logo when the game starts is a bit jumbled up (but do you really care?).

Game: Astrox Imperium
Version: b 0.089 (64-bit)
Installer MD5: a7a5a45eefea76e2a0419f53faf61d26 setup_astrox_imperium_b_0.089_(64bit)_(35219).exe
WineHQ AppDB Link: --not available--

Distro: Linux Mint 19.2 Tina | Cinnamon | 64-bit
Kernel: 4.15.0-74-generic
Graphics: NVidia GeForce GTX 670
CPU: Intel i7-3930K @ 3.20GHz × 6
Wine Version: Wine Staging 5.0-rc5 64-bit

Install Notes:
• Standard install.
• No winetricks necessary.
• Usual 4 popups at installer completion.

How does it run:
• Appears to be locked at 30fps, but this is common with Unity games.
• The game runs well in full screen -- windowed mode can be an issue if the mouse leaves the window (see caveat below).
• Caveat: Alt-Tab / switching applications breaks keyboard/mouse input upon return. The process usually has to be killed manually when this happens.

Details:
• Windows 7 compatibility.
• Also tested in the Lutris-4.21 wine engine and had the same Alt+Tab input issues.
• Played about 5 hours without issue as long as I didn't switch applications.
• Usually upon returning to the game only the left mouse button works (if anything). No right click, scroll wheel, or keyboard input is recognized.
• Just saving, exiting, and reloading at a station when I have to switch windows for now -- it's not ideal, but quick enough.

I have sound issues with the game (a lot of noise interference), which is only partially resolved by setting PULSE_LATENCY_MSEC environment variable. Have you noticed anything like that?

No, but I believe the laptop I am using is not running pulseaudio.

Anyway, I would *really* like someone to test The Alliance Alive and report back, so I know whether I can buy that game. (Game is too expensive for me without confirmation that it works.)

OK, thanks. I'll have to look into this more.

Edit: switching from vanilla wine 4.0.2 to wine-staging 4.21 solves the problem completely even without altering pulseaudio variables. I also don't see any problems with the logo at the start of the game (I had that problem, too, in wine 4.0.2). I tested in a clean prefix without any dll overrides.

Can anyone please check. I re-installed Outlaws in Wine, applied winmm fix, and it's generally working both through glide/Vulkan and wined3d/OpenGL, but there is a weird bug now, that aiming is messed up. Basically, it shoots quite above your crosshair, which makes it almost impossible to play. Did anyone notice that? Is it some kind of resolution or aspect ratio related issue? I tried running it in original 640x480, but the same problem occurs.

My monitor is 2560x1440, 144 Hz. I wonder if it affects it.

I remember in the past aiming worked fine, on older monitor.

UPDATE: I figured, it's by design, since when you enable the crosshair, it's quite above too. Is there some way to aim when weapon's crosshair is actually aligned?