mirror of
https://github.com/torvalds/linux.git
synced 2024-11-01 01:31:44 +00:00
4d7bf11d64
Taken from http://bugzilla.kernel.org/show_bug.cgi?id=5079 signed long ranges from -2.147.483.648 to 2.147.483.647 on x86 32bit 10000011110110100100111110111101 .. -2,082,844,739 10000011110110100100111110111101 .. 2,212,122,557 <- this currently gets stored on the disk but when converting it to a 64bit signed long value it loses its sign and becomes positive. Cc: Andreas Dilger <adilger@dilger.ca> Cc: <linux-ext4@vger.kernel.org> Andreas says: This patch is now treating timestamps with the high bit set as negative times (before Jan 1, 1970). This means we lose 1/2 of the possible range of timestamps (lopping off 68 years before unix timestamp overflow - now only 30 years away :-) to handle the extremely rare case of setting timestamps into the distant past. If we are only interested in fixing the underflow case, we could just limit the values to 0 instead of storing negative values. At worst this will skew the timestamp by a few hours for timezones in the far east (files would still show Jan 1, 1970 in "ls -l" output). That said, it seems 32-bit systems (mine at least) allow files to be set into the past (01/01/1907 works fine) so it seems this patch is bringing the x86_64 behaviour into sync with other kernels. On the plus side, we have a patch that is ready to add nanosecond timestamps to ext3 and as an added bonus adds 2 high bits to the on-disk timestamp so this extends the maximum date to 2242. Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> |
||
---|---|---|
.. | ||
acl.c | ||
acl.h | ||
balloc.c | ||
bitmap.c | ||
dir.c | ||
ext4_jbd2.c | ||
extents.c | ||
file.c | ||
fsync.c | ||
hash.c | ||
ialloc.c | ||
inode.c | ||
ioctl.c | ||
Makefile | ||
namei.c | ||
namei.h | ||
resize.c | ||
super.c | ||
symlink.c | ||
xattr_security.c | ||
xattr_trusted.c | ||
xattr_user.c | ||
xattr.c | ||
xattr.h |