On Wed, Mar 01, 2023 at 03:26:04PM +0100, Michal Suchánek wrote: > > Last time I asked about this file on this mailing list, I was > > informed that clock.txt is supposed to survive reboots. > > Moving it to /run (or any other tmpfs) would break this. > > What's so valuable in it that it needs to survive? > > I don't have it at all. > > Also the code seems to re-synchronize with the real time clock from time > to time which makes the content relevant only for limited periods of > time. The concern is if the system time goes backwards, this could result in a duplicative UUID being returned. This was especially a concern for systems that were dual-booting with Windows, where Windows set the real-time clock to localtime, and Linux set the real-time clock to GMT, and so the real time clock on those systems had a tendency to bound around a *lot*. Using a random number generator for clock can help, but it's only 13 bits, so it's certainly not fool-proof. Given that using a time-based UUID leaks the MAC address of your ethernet port as well as when the UUID was generated (which can be interesting when you're curious say, when a Libreoffice doc was created), in general best practice is to use the random UUID type, especially given that modern Linux systems all have the getrandom(2) system call. That gives you 58 bits of entropy in the UUID, so that's probably the better way to go. Cheers, - Ted
