http://bugs.winehq.org/show_bug.cgi?id=58529 --- Comment #10 from Ken Sharp <imwellcushtymelike(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.