https://bugs.winehq.org/show_bug.cgi?id=49160
--- Comment #4 from Jamieson Christian jamiesonc2@gmail.com --- (In reply to Hans Leidekker from comment #3)
Under dbus, there's /var/lib/dbus/machine-id, which on some distros is simply a symlink to /etc/machine-id. Neither requires root access. On Ubuntu 20.04, /var/lib/dbus/machine-id is a symlink, and /etc/machine-id remains consistent between boots. (On a permanent OS install; stateless boot is a different matter.)
Right, we already use this ID for Win32_ComputerSystemProduct.UUID.
Ah, that would be redundant, then. Maybe we don't bother trying to populate this one. See my concluding notes at bottom of post.
This CLI technique hints at a possible approach:
udevadm info --query=all --name=sda | grep SERIAL=
The above seems to produce a distillation of /sys/block/sda/device/wwid
I was thinking of querying UDisks2.Drive.Id through dbus, which should return the same thing.
More or less the same, from what I see in d-feet. It's a concatenation of elements, as shown below:
by-id-{INTERFACE}-{MFG}_{MODEL}_{SERIAL}
(Where {INTERFACE} is e.g. "ata")
Perhaps easy enough to extract just the serial # portion, but the whole thing could probably just be used as is, you think?
We should read this from HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProductId. While this is currently also set to a fixed value it would at least give users the opportunity to change the value. I guess we could improve on this by generating a unique value on prefix creation.
This sounds like a good approach. Generating a unique value is ideal.
Some googling leads me to believe that this isn't really a unique ID. It's still a good idea to retrieve this from the registry.
What I've read suggests that its *persistence* is not guaranteed on Windows systems; Windows 10 updates have been known to result in a new product ID. But it probably doesn't change how we choose to implement it. The goal (tell me if you think differently) should be "reasonably unique and reasonably persistent".
CONCLUSION: From our discussion, it looks like the population of some of these values has no clear solution path. That's probably fine. As long as we are able to obtain reasonably diverse values for 2 or 3 of these, it should satisfy the need for a "reasonably unique" value in Unity's SystemInfo.deviceUniqueIdentifier.