SUMMARY (addendum) Y2K1 problem w/ Tru64 4.0 cdfs timestamps

From: Franz Fischer <Franz.Fischer_at_franz-fischer.de>
Date: Mon, 17 Sep 2001 21:18:53 +0200 (MET DST)

Some more info (for those interested):

interestingly, after applying the patch, the timestamps reported by stat(2)
are fine, however, the cdsuf(1) program (assumed to use cd_suf(3) which is
part of libcdrom.{a,so}) still shows the begin of the epoch:

ofen_& ls -l INDEX # INDEX is a file on a cdfs
-r--r--r-- 1 root system 3052136 Sep 3 13:17 INDEX
ofen_& cdsuf INDEX
Signature Length Version Data
RR 5 1 fields present: PX NM TF
NM 10 1 INDEX
PX 36 1 mode 100444 nlink 1 uid 0 gid 0
TF 26 1 modify: Thu Jan 1 01:00:00 1970
                                access: Thu Jan 1 01:00:00 1970
                                attributes: Thu Jan 1 01:00:00 1970

ofen_& nm /usr/lib/libcdrom.a | grep cdfs_tounixdate
cdfs_tounixdate | 0000000000000000 | U | 0000000000000008
cdfs_tounixdate | 0000000000000992 | T | 0000000000000008
(Obviously same broken code as in the kernel and not replaced by the patch
--- at least not on 4.0D.)

Ok, if cdfs had reported correct times, I would not even know of cdsuf(1) /
cd_suf(3), so I can live with the buggy libcdrom / cdsuf.

(Hopefully libcdrom and the kernel use the same source base so that 5.1A has
fixed both.)

Regards
        \franz
--
Franz G. Fischer ----------------------------- Franz.Fischer_at_franz-fischer.de
Received on Mon Sep 17 2001 - 19:20:09 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:42 NZDT