someone ort to fix this Begin forwarded message: Date: Sat, 16 Jun 2007 17:50:35 -0700 (PDT) From: bugme-daemon@xxxxxxxxxxxxxxxxxxx To: bugme-new@xxxxxxxxxxxxxx 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@xxxxxxxx ReportedBy: markus.mottl@xxxxxxxxx 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
