Bug 8643 - Bug with negative timestamps on 64bit machines
Summary: Bug with negative timestamps on 64bit machines
Status: RESOLVED DUPLICATE of bug 5079
Alias: None
Product: File System
Classification: Unclassified
Component: ext3 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Andrew Morton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-06-16 17:53 UTC by Markus Mottl
Modified: 2007-06-17 03:01 UTC (History)
0 users

See Also:
Kernel Version: 2.6.21-1.3228.fc7
Tree: Fedora
Regression: ---


Attachments

Description Markus Mottl 2007-06-16 17:53:49 UTC
Most recent kernel where this bug did not occur:
Distribution: Fedora Core 7
Hardware Environment: AMD Athlon 64
Software Environment:
Problem Description:

Negative timestamps (i.e. before 1970) are incorrectly handled due to some obvious 64bit issues.  They show up normally as long as the cache has not been purged.

Steps to reproduce:

Touch a file in an ext3-file system with a negative timestamp, e.g.:

  # touch -t 196901010000 /opt/foo

Unless you have been writing a lot of data to this partition after the last command, the next one should display the following:

  #  ls -l /opt/foo
  -rw-r--r-- 1 root root 0 1969-01-01 00:00 /opt/foo

This is still correct.  But now we purge the file system cache by unmounting and mounting the partition again:

  # umount /opt/foo
  # mount /opt/foo

Now the timestamp will be corrupted:

  # ls -l /opt/foo 
  -rw-r--r-- 1 root root 0 2105-02-07 06:28 /opt/foo

It seems obvious that the upper 32 bits of the 64 bits representing the time stamp get lost, which explains the above observation.

On 32bit architectures there is no such problem.  I haven't managed to reproduce this problem with other file systems (e.g. XFS).
Comment 1 Dmitry Monakhov 2007-06-17 02:41:32 UTC
duplicate: http://bugzilla.kernel.org/show_bug.cgi?id=5079
fixed by:
commit 4d7bf11d649c72621ca31b8ea12b9c94af380e63
Author: Markus Rechberger <Markus.Rechberger@amd.com>
Date:   Tue May 8 00:23:39 2007 -0700
Comment 2 Andrew Morton 2007-06-17 03:01:12 UTC

*** This bug has been marked as a duplicate of bug 5079 ***

Note You need to log in before you can comment on or make changes to this bug.