In one of my apps, I was “cleverly” using a hash of Volume(0).CreationDateTime as a quick & dirty way to uniquely identiy different computers.
I’ve just now learned that this doesn’t work very well - for example I checked two completely different mac computers, both running 12.5, and on both of them, Volume(0) has a creation (and modification date) of 14 July 2022 at 1:48am.
I’m pretty sure this is a new behavior for macOS related to the sealed System.
Would using a different folderItem make more sense, e.g. perhaps /System/Volumes/Data ?
(This is for analytics for software installations. It doesn’t have to be high security, but it would be nice to have it working properly).
I believe the CreationDate could be written into the chips automated or it could be a xojo bug, eighter way i’d be using a Serial number (hashed) or the MBS SystemInformation Machine Id to be as unique as possible.
That’s rather odd. Out of curiosity, I checked mine and it’s also 14 July 2022 at 10:48 (because of a different time zone). We can’t both have installed a new MacOS (should this be the reason why the disk had a new creation date and time) at the exact same time, can we?
What could possibly have triggered a creation date/time at that exact moment?
One common approach is to use a network MAC address, from an Ethernet port or a wireless connection. Those are guaranteed to be unique unless the user is spoofing them, which is pretty unlikely but not impossible.
If you don’t want to do that, how about the creation date of the user’s home folder, perhaps combined with their username?
For the volume’s content, this makes much sense.
For the volume itself, I’d say it’s something I didn’t expected. This means the volume’s metadata has been replaced by the one from the downloaded&installed OS, while I’d have expected a volume to keep its partitioning date&time.
Bug, feature or not even considered behaviour?