Date: Tue, 30 Mar 1999 21:06:47 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: ksmm@threespace.com (The Classiest Man Alive) Cc: tlambert@primenet.com, freebsd-chat@FreeBSD.ORG Subject: Re: FreeBSD is running out of time Message-ID: <199903302106.OAA00916@usr04.primenet.com> In-Reply-To: <Version.32.19990330144219.00ef97e0@mail.cybercom.net> from "The Classiest Man Alive" at Mar 30, 99 02:45:11 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> So what are these additional fields being used for now? And is there a > solution available or in the works to solve the 2038 bug in FreeBSD? Or > will we just all be using Linux after that point? :-/ > > >Well, as long as we are beating dead horses here... > > > >IMO, it is *silly* that FreeBSD coopted the fields in FFS that were > >reserved for dealing with the Y2038 "bug", which technically didn't > >exist in BSD 4.4 until these fields were coopted. > > > >But then, who am I to look 39 years into the future, instead of only > >6 months ahead, like everyone else. The fields were coopted for nanosecond "accuracy" for the make(1) modification time dependency to support sub-second granularity. Since only the modification time has this exposure requirement, this could have easily been accomplished via use of a spare field. In reality, the requirement only exists for generated files for which the graph closure is dynamically updated between the time of the file generation and the next run. Basically, in order to trigger a "problem" from, this, you would need to generate a generated file from a generated file during a 3 Makefile recursive descent, or you would need a two Makefile lateral dependency (this is just bad Makefile coding, but it's a possible scenario). The failure mode would cause the regeneration of the target file; in other words, the failure is harmless. An alternate workaround would be to ensure that the time has increased from the last stamping. This is a potential "round up" to one second for all operations. Considering that what we're talking about is subsecond operations, redoing the operation is hardly a hardship, though it might cause your "make world" ``benchmark'' to take a second more than it would have (big whoop). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903302106.OAA00916>