Re: Fw: [Bugme-new] [Bug 8643] New: Bug with negative timestamps on 64bit machines

[Dmitriy Monakhov <dmonakhov@sw.ru>]

On 23:05 Сбт 16 Июн     , Andrew Morton wrote:
> 
> someone ort to fix this
duplicate: http://bugzilla.kernel.org/show_bug.cgi?id=5079
Already fixed by:
commit 4d7bf11d649c72621ca31b8ea12b9c94af380e63
Author: Markus Rechberger <Markus.Rechberger@amd.com>
Date:   Tue May 8 00:23:39 2007 -0700
I don't have sufficient permission to change bug status, so
let's someone else do it.
> 
> 
> Begin forwarded message:
> 
> Date: Sat, 16 Jun 2007 17:50:35 -0700 (PDT)
> From: bugme-daemon@bugzilla.kernel.org
> To: bugme-new@lists.osdl.org
> Subject: [Bugme-new] [Bug 8643] New: Bug with negative timestamps on 64bit machines
> 
> 
> http://bugzilla.kernel.org/show_bug.cgi?id=8643
> 
>            Summary: Bug with negative timestamps on 64bit machines
>            Product: File System
>            Version: 2.5
>      KernelVersion: 2.6.21-1.3228.fc7
>           Platform: All
>         OS/Version: Linux
>               Tree: Fedora
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: ext3
>         AssignedTo: akpm@osdl.org
>         ReportedBy: markus.mottl@gmail.com
> 
> 
> 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).
> 
> 
> -- 
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html