Hi,
thanks to
"Senn, Bruce" <sennb_at_union.edu>
"Dr. Thomas.Blinn_at_Compaq.com" <tpb_at_doctor.zk3.dec.com>
Olle Eriksson <olle_at_cb.uu.se>
"Wagner, Ronald P" <ronald.p.wagner_at_lmco.com>
As usual, most comprehensive answer came from Dr. Tom (see below).
- Yes, there is a bug in Tru64 4.0D..G (and presumably all before),
5.0 and 5.1.
- The bug is fixed in 5.1A.
- Patches are available for all currently supported versions. (Obviously
the bug was discovered early this year and at bug fixing time 4.0D was
still supported, so patches seem to be available for 4.0D-G.)
http://ftp1.support.compaq.com/public/Digital_UNIX/*/cdfsdate*
- The timestamps on the media (generated w/ mkisofs) are ok.
- No, its not a 10 digit rollover :-)
> To: Franz Fischer <Franz.Fischer_at_franz-fischer.de>
> Subject: Re: Y2K1 problem w/ Tru64 4.0 cdfs timestamps?
> In-reply-to: Your message of "Sun, 16 Sep 2001 14:25:18 +0200."
> Date: Sun, 16 Sep 2001 12:41:15 -0400
> From: "Dr. Thomas.Blinn_at_Compaq.com" <tpb_at_doctor.zk3.dec.com>
>
> It's a bug in Tru64 UNIX. It was discovered shortly after the beginning
> of the year 2001. There are patches for all the currently supported
> versions, which includes V4.0F and V4.0G but probably NOT for V4.0D or
> V4.0E (since they are NO LONGER SUPPORTED by Compaq), and of course for
> the supported releases in the V5.x stream. The bug is fixed in V5.1A
> which just released in the US. The bug is in the CDFS code as I recall,
> not in the higher level code, and as I recall, it impacts the READING
> of the media, not the writing (the dates on the media are correct, so
> when you look at the media on, say, a Linux system, they are fine).
>
> By the way, if you do the backup to a normal file, the timestamps inside
> the backup saveset are fine; it's the interpretation of the timestamp on
> the wrapper file that's wrong. So, if you copy a backup file onto CD-R
> media, it will have what appears to be the wrong "date copied" until you
> get the patch and apply it.
>
> Tom
> [...]
Franz Fischer's Mail:
> while doing some backups to CD-R, I noticed, that I see files and directories
> with an original modification time of this year (2001) reported on the
> ``backup CD'' as Jan 1 1970 (i.e. begin of the epoch).
>
> The CD image was created with mkisofs-1.9/-1.10 and I see the effect on
> both, images with and without RRIP extensions. (RRIP case tested on 4.0D +
> 4.0F, non-RRIP only tested on 4.0D so far.) For images with RRIP, cdsuf
> shows the presence of the TF field, but a wrong date for files/dirs with
> year >= 2001.
>
> However, timestamps are shown correctly when mounting the CD on a Linux system.
>
> Has anybody else seen this behaviour so far? Is it a Tru64 cdfs bug or are
> mkisofs + Linux wrong in the same way? (There is a certain probability for
> the latter as both are free source, but why are timestamps below and
> including year 2000 shown correctly on both systems, while those beginning
> with 2001 are incorrect on the combination mkisofs + Tru64 4.0{D,F} only?)
> Is it fixed in 4.0G (if its a Tru64 bug)?
> [...]
> PS: No, its not a 9 digit overflow problem somewhere: A file with
> st_mtime = 986151268 (April 1st, 2001) is also reported as
> Jan 1 1970 on the mounted ISO file system on 4.0D.
Regards
\franz
--
Franz G. Fischer ----------------------------- Franz.Fischer_at_franz-fischer.de
Received on Mon Sep 17 2001 - 18:47:15 NZST