[ On Thursday, March 25, 1999 at 17:40:38 (-0500), John F. Woods wrote: ]
> Subject: Re: Y2038, was as long as we're hitting FFS... 
>
> One could argue that you might be able to get away without versioning the
> inode for this particular change.

[[ Drat.  I hate it when threads don't work right!  Why can't everyone
on these lists use a mailer that preserves References?!?!?!?  ;-) ]]

> Consider:  no existing inodes should have the high-order bit set in the
> time, so existing filesystems are treated correctly by updated code.  The
> reverse isn't true, of course, but it will be over 38 years before any
> systems will have the opportunity to misunderstand a "new" inode (except,
> of course, for deliberate tests or the occasional accident where someone
> sets their clock WAY too far forward -- once that becomes possible,
> of course!).

I wouldn't even worry about that problem, even if today were some day in
2037 and we were desparate for a quick fix.

If you move forward and create timestamps with the high bit set and then
boot a kernel that interprets that as a sign bit then you'll have some
files that appear to be really old.  So what?  If your old kernel's
clock happens to be set to a negative number maybe  it'll count
backwards too.  These things would happen anyway if this fix were only
finally being implemented in 2037 and you wanted to try an old kernel
sometime after the roll-over, and by then only drastic solutions would
work anyway, such as forcing you to newfs-64 your filesystems and
restore from your backups anyway, in which case you can't boot an old
system again.

Changing the filesystem version number is probably more disruptive than
worrying about those few people who will make the mistake of booting a
really old kernel or using an old libc after 2038 -- their consequences
aren't too difficult to undo or work around anyway.

The only real problems are likely to be in "applications" which don't
include and use the system's definition of "time_t" (many use "long"),
but they'll have the same problem with a 64-bit signed time_t, so they
are a problem no matter what you do (actually less of a problem with an
unsigned time_t because not all will have checks for negative values).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>