Date: Thu, 25 Oct 2001 19:03:30 -0600 From: Brad Huntting <huntting@hunkular.glarp.com> To: Peter Wemm <peter@wemm.org> Cc: arch@FreeBSD.ORG Subject: Re: 64 bit times revisited.. Message-ID: <200110260103.f9Q13UE45171@hunkular.glarp.com> In-Reply-To: Your message of "Thu, 25 Oct 2001 16:36:02 PDT." <20011025233602.587C63808@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> sizeof(time_t) exposed: > /etc/pwd.db (pw_change, pw_expire) > /var/run/utmp (ut_time) > /var/log/lastlog (ll_time) > /var/db/acct (ac_btime - begin time of a process) These files are rarely, if ever seen by other machines, so it would be easy enough to either convert, delete, or recreate them at upgrade time. > dump/restore tape format (spcl. c_data, d_ddate, etc) This should probably change hand in hand with ufs. > notable exceptions where times are explicitly sized: > ufs inode format (has ufs_time_t == 32 bits explicitly) Upgrading ufs and dump/restore to "big time" can be independent of other FreeBSD "big time" issues. After all, ufs has other size limitations, most notably ino_t which will begin biting long before 2038. > nfs (uses 32 bit timestamps in v3, and 64 bit on v4 (I believe)). This is something we cant change without forsaking interoperability, so let's not worry about it. > notable exceptions where times are *ambiguous*: > rpc on-the-wire (both int, u_int, long and u_long timestamps (!)) > yp/nis (uses u_long ctime, mtime - see struct nis_oid) Like nfs, we may need to corrupt time_t to 32 bits for some of these to maintain interoperability, but we cant expect to change established Internet protocols before upgrading to 64 bit time_t. > So.. What do people think? Let the bikeshedding begin... I dont see that switching all platforms to 64 bit time_t is that big a deal. Is time_t really that much more trouble than off_t? brad To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110260103.f9Q13UE45171>