Bug 101723 – timestamp Jan 1, 1970 is altered to Feb 7, 2106 after re-mount of ext3 file system

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Shigeru Akiyama 2005-08-08 03:12:57 UTC]

I have been using an artificial timestamp Jan 1, 1970 for archiving purpose.
Today I found that all these files have timestamp Feb 7, 2106. These files are
on ext3 file system. For testing, I created a file with timestamp Dec 31, 1969
and unmounted the partition. When re-mounted, this file had timestamp Feb 6,
2106. It seems that underflow of 32-bit integer is occurring. More recent
timestamp like Dec 31, 1980 is not affected.

I have never experienced this type of problem before.


Reproducible: Always
Steps to Reproduce:
1.
2.
3.




root:~# emerge info
Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.5-r0,
2.6.12-gentoo-r6 x86_64)
=================================================================
System uname: 2.6.12-gentoo-r6 x86_64 Intel(R) Pentium(R) 4 CPU 3.00GHz
Gentoo Base System version 1.6.13
dev-lang/python:     2.3.5
sys-apps/sandbox:    1.2.11
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=nocona -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=nocona -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="ftp://ftp.ecc.u-tokyo.ac.jp/GENTOO http://mirror.gentoo.gr.jp
http://gentoo.gg3.net/ http://mirror.averse.net/pub/gentoo/
http://gentoo.channelx.biz/ http://gentoo.arcticnetwork.ca/
http://cudlug.cudenver.edu/gentoo/ http://ftp.gentoo.or.kr/
ftp://gg3.net/pub/linux/gentoo/ http://gentoo.mirrors.easynews.com/linux/gentoo/"
LINGUAS="en ja"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X alsa avi berkdb bitmap-fonts cdr crypt cups curl eds encode esd fam
foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 imagemagick imlib ipv6
java jpeg kde libwww lzw lzw-tiff mad motif mp3 mpeg mysql ncurses nls ogg
opengl pam pdflib perl png python qt quicktime readline ruby sdl slang spell ssl
tcltk tcpd tetex tiff truetype-fonts type1-fonts usb userlocales vorbis xine
xml2 xmms xpm xv zlib linguas_en linguas_ja userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY

[Comment 1 Carlos Silva (RETIRED) 2005-08-08 14:58:55 UTC]

can you reproduce this problem in any other filesystem type or it just occurs in
ext3?

[Comment 2 Shigeru Akiyama 2005-08-09 15:50:10 UTC]

Additional information:

If I access the same partition from x86 Gentoo, timestamps `Jan 1, 1970' and
`Dec 31, 1969' are still there.

It seems that function `stat()' on amd64 is behaving strangely.

Reply to the previous comment: I don't have an ext2 partition.

[Comment 3 Shigeru Akiyama 2005-08-09 21:09:10 UTC]

Correction:

I don't have a partition other than ext3.

[Comment 4 Carlos Silva (RETIRED) 2005-08-11 03:10:20 UTC]

can you please post your timezone?
ls -lh /etc/localtime would be ok.

[Comment 5 Shigeru Akiyama 2005-08-11 03:39:38 UTC]

root:~# ls -lh /etc/localtime
lrwxrwxrwx  1 root root 25 Jul 21 09:00 /etc/localtime -> /usr/share/zoneinfo/Japan

[Comment 6 Carlos Silva (RETIRED) 2005-08-17 12:59:15 UTC]

can you please try to reproduce this bug in plain vanilla kernel?

[Comment 7 Shigeru Akiyama 2005-08-17 16:19:54 UTC]

This bug was found approx. 2 weeks after I had updated the kernel. I am sure all
timestamps were OK for that period. It must be some package (or a combination of
packages) I installed or updated around Aug. 6-7 that induced this bug.

It will be a daunting task to try out packages and more packages.

Is there some kind of test script to run to locate a buggy part?

[Comment 8 Carlos Silva (RETIRED) 2005-08-17 17:01:14 UTC]

You can start by using genlop to reduce the possible packages that 'cause the
problem. after that, all you can do is to try reinstall some packages that can
'cause that kind of breakage on the system...

[Comment 9 Daniel Drake (RETIRED) 2005-08-18 02:31:25 UTC]

It's almost certainly a kernel thing. Please just confirm the problem still
exists on the latest development kernel (currently vanilla-sources-2.6.13_rc6)

[Comment 10 Shigeru Akiyama 2005-08-18 05:39:23 UTC]

I have tested `vanilla-sources-2.6.13_rc6'.

Still, timestamp Feb 7, 2106 is displayed instead of Jan 1, 1970.

[Comment 11 Carlos Silva (RETIRED) 2005-08-23 08:00:44 UTC]

Closing as upstream bug.