On Wed, Mar 01, 2023 at 11:49:57AM -0500, Theodore Ts'o wrote: > 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. That explains why I don't have a clock.txt file. I did not go out of my way to generate time-based uuids. Thanks Michal
