Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 101723 - timestamp Jan 1, 1970 is altered to Feb 7, 2106 after re-mount of ext3 file system
Summary: timestamp Jan 1, 1970 is altered to Feb 7, 2106 after re-mount of ext3 file s...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
Depends on:
Reported: 2005-08-08 03:12 UTC by Shigeru Akiyama
Modified: 2012-11-02 12:20 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
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:

root:~# emerge info
Portage (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/libtool:   1.5.18-r1
virtual/os-headers:  2.6.11-r2
CFLAGS="-march=nocona -O2 -pipe"
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"
FEATURES="autoconfig distlocks sandbox sfperms strict"
LINGUAS="en ja"
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"
Comment 1 Carlos Silva (RETIRED) gentoo-dev 2005-08-08 14:58:55 UTC
can you reproduce this problem in any other filesystem type or it just occurs in
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

I don't have a partition other than ext3.
Comment 4 Carlos Silva (RETIRED) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 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) gentoo-dev 2005-08-23 08:00:44 UTC
Closing as upstream bug.