http://bugs.winehq.org/show_bug.cgi?id=59118 Bug ID: 59118 Summary: 32-bit WINE does not work correctly with 32-bit device IDs and 64-bit inodes Product: Wine Version: 11.0-rc1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs@list.winehq.org Reporter: e.j.bennett@swansea.ac.uk Distribution: --- Created attachment 79937 --> http://bugs.winehq.org/attachment.cgi?id=79937 Log showing command run, error, and location of correct directory When Wine starts, Wineserver uses the device and inode IDs of the `~/.wine` directory to name a temporary directory (`/tmp/.wine-${UID}/server-${DEVICE_ID_IN_HEX}-${INODE_ID_IN_HEX}`). A lock file and socket are created in this directory that the Wine client then (I presume) uses to communicate with Wineserver. When running on our HPC cluster with a Lustre filesystem, Wineserver creates this directory with a different name to the one that the client uses to look for it. Specifically, it is created with a 32-bit device ID and 64-bit inode ID, but read with a 16-bit device ID and 32-bit inode ID. The truncated device ID is simply the last 16 bits of the full 32-bit ID, but it is not clear to me how the truncated inode ID is related---the last 12 bits appear the same, but the remainder does not line up. The machine is running CentOS 7; as far as I know no official packages are available, and I'm not able to build 32-bit Wine due to a lack of a 32-bit toolchain, so I am running in an Apptainer container. To my knowledge this shouldn't affect the behaviour observed; running `stat ~/.wine` inside the container returns the same inode number as running it outside the container. -- 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.