On Thu, Jul 02, 2020 at 09:16:28AM +0200, Egmont Koblinger wrote: > Hi Greg, > > > What is this "problem" causing today? > > This is probably only a cosmetic issue, rather than a > strictly-speaking bug. I mean, the tty line works fine, and the 8 > second resolution is a nice prevention against security/privacy > issues. I'm not aware of any misbehavior in any application (which, > of course, does not guarantee that there isn't any). Given that this change has been in linux for over 7 years (was introduced in 2013), I'm sure we would have been told of any misbehavior by now :) > That being said, the device regularly having a future timestamp (and > in turn, "ls -l" using a different formatting) is totally unexpected, > and made me (and perhaps will make others) think that there must be > something wrong with the system. > > Is this a bug in coreutils's "ls"? (That was my first suspect.) ... > Or am I experiencing clock skews? Due to a hardware flaw? Due to an > ntp problem? Is there a chance it'll affect some apps too? ... Or > what else could it be? ... -- I was wondering. > > If the code cares enough to update the timestamp at all -- which I > would be fine without, I personally wouldn't mind if it stayed at the > creation time of that tty line, or was always the Epoch --, and cares > enough to reduce the precision -- which I find a good thing --, then I > guess it should also take care of not setting it to a future > timestamp, in order not to cause unexpected end-user results in "ls > -l" and who knows what other tools. We are doing a simple "knock the lower bits off and check" calculation to make this fast, as it needs to be fast. As for setting it in the future, I don't think that's what is happening here, you are just comparing two things that can't be compared as they are not the same thing. thanks, greg k-h
