http://bugs.winehq.org/show_bug.cgi?id=58529
--- Comment #10 from Ken Sharp imwellcushtymelike@gmail.com --- (In reply to Eric Pouech from comment #3)
when you write in #1 that you tried different fs, for which mount point was it?
I created multiple mount points (named btrfs, ext4, etc.) and pointed the wineprefix to them. Installation completes with z: removed.
maybe unrelated (but could be from symptoms), but would one of your mounted fs be btrfs with subvolumes used?
My test mount points didn't use subvolumes. My system uses subvolumes. / and /home span multiple SSDs, and another spinning disk which also uses subvolumes. The installation works when installing to either of these.
(In reply to Hans Leidekker from comment #4)
Looks like it picks the drive with the largest amount of free space.
Tested on Win 10 and this is exactly what happens.
I suspect it will fail in the same way on Windows if the chosen drive happens to be read-only.
In Win 10 it does indeed fail, but the installer actually tells you that it cannot write to the drive, allows you to cancel and claims to rollback, though it leaves c:\NotesSQL behind, which it always chooses c: (or maybe %systemdrive%) for.
So there's possibly an additional issue here: the installer isn't being told that the drive is readonly, or the installer doesn't know what to when it is told, OR it is related to how msiexec is run (/qf? /qb?). https://bugs.winehq.org/show_bug.cgi?id=37833#c1