On 22. Sep 2025, at 20:31, Paul Gofman pgofman@codeweavers.com wrote:
On 9/22/25 12:14, Elizabeth Figura wrote:
On the other hand, I am reminded of an unrelated bug, involving a program (I don't have the name unfortunately) which copies ws2_32.dll to a temp file with a randomly generated name and attempts to load the copy. This fails on Wine because ws2_32 has a unixlib, and we derive the name of the unixlib from the path of the DLL. In order to fix this bug we would probably need to embed the name of the unixlib in the DLL itself rather than relying on its path. If we did that the DLLs for winepulse and winealsa would no longer be identical.
That doesn't look quite related to the discussed issue? This part is about how we find Unix library. I didn't check exactly this case lately but doesn't Wine search for Unix libraries in the configured or determined on start Wine paths now? I'd guess it might just work?
For the original issue, having the same inodes for different files looks clearly like a bug in NixOS to me. First, yes, if there are two differently named files they are different files even if the contents happens to be the same. For one, the contents is identical right now but may change, and if those are differently named files the contents is not synchronous between those. Then, inode is supposed to be unique within the same file system: https://man7.org/linux/man-pages/man7/inode.7.html, "Inode number": "Each file in a filesystem has a unique inode number.".
I think they can mostly get away with this because the nix store is by design read-only (and there are in practice many duplicates there). Though I agree that such a form of deduplication should happen on the filesystem layer ideally.