On 9/22/25 19:20, Yuxuan Shui wrote:
Hi,
On Mon, Sep 22, 2025 at 7:49 PM Marc-Aurel Zentmzent@codeweavers.com wrote:
On 22. Sep 2025, at 20:39, Paul Gofmanpgofman@codeweavers.com wrote:
On 9/22/25 12:37, Marc-Aurel Zent wrote:
On 22. Sep 2025, at 20:31, Paul Gofmanpgofman@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.
But also I don't quite understand from the description why that happens to winepulse.drv and winealsa.drv, these files are not indentical and have different contents??
For me at least winepulse.drv and winealsa.drv are in content exactly identical. If nix were to deduplicate only cross-derivation this would not happen I think.
Yes, this will be a solution indeed. I think I saw people mentioning this on the nix issue tracker.
This is not a solution, this is a workaround for a particular case of the problem. The similar issue may happen with app's dll loaded from different directories, or other (more special) cases not related to loading dlls. FWIW Wine behaviour checking underlying file identity is not random. For instance, LdrGetModuleHandle called with full DLL path will distinguish dll which was renamed (while loaded) and replaced by different file, we have a test for that (and that's one example where correct file identification is needed).
The problem is not Wine specific, identifying files by inode within FS is what other Unix apps can rightfully do, making deduplication look like a hard link (made on behalf of the app) which then gets "unlinked" when either file is modified is severe change of Unix inode semantics and IMO should be fixed.