Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA Path: utzoo!linus!philabs!prls!amdimage!amdcad!decwrl!ucbvax!daemon From: tcp-ip@ucbvax.ARPA Newsgroups: fa.tcp-ip Subject: voting on the time Message-ID: <10028@ucbvax.ARPA> Date: Tue, 20-Aug-85 17:47:54 EDT Article-I.D.: ucbvax.10028 Posted: Tue Aug 20 17:47:54 1985 Date-Received: Fri, 23-Aug-85 20:27:05 EDT Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 48 From: Christopher C. StacyDate: Tue, 20 Aug 85 13:39 EDT From: David C. Plummer in disguise To: Christopher C. Stacy , jsq%tzec.UTEXAS at UT-SALLY.ARPA cc: TCP-IP at SRI-NIC.ARPA Re: voting on the time In-Reply-To: <[MIT-MC.ARPA].618951.850820.CSTACY> Date: Tue, 20 Aug 85 12:19:13 EDT From: Christopher C. Stacy When voting on the time, another piece of information which almost everyone has at their disposal is the reference date of certain files which must be accessed when the system is run. This can be used as an error check against the propogation of bad times (which has happenned occasionally on our local network). Network (or other) times preceeding the file date are probably bogus. But what happens if somebody spazzes and warps MIT-MC 9 months into the future. (It has happened before.) What if one of the files you check against was created by such a time-warped machine? Indeed, the normal case will be caught by your probable-bogosity meter, but when the baseline is bogus, then what? Yeah, that's a pretty awful state to get into. Part of the recovery strategy for a file system which was active with the wrong time should be to locate (important) files which may have been written with the wrong date and fix them to sometime in the past, perhaps the shutdown time. The file date hack is not intended as a recovery mechanism for bad times. It is merely another source of information that tells you when things appear inconsistant. Some human who knows better can come along and consult a sundial or something to decide which time is really correct. Also, the file date check is only useful for fairly gross times. It might be appropriate to use it when booting the system to see if tomorrow is yesterday, but I wouldn't bother trying to use it for second (or minute) accuracy. What about systems who can't access the filesystem until the time is known? That's what "almost everyone" in my statement refers to. You obviously can't use this hack if you can't read the file directory information.