summaryrefslogtreecommitdiffstats
path: root/CREDITS
diff options
context:
space:
mode:
authorArnd Bergmann <arnd@arndb.de>2018-07-13 16:47:17 +0200
committerBoris Brezillon <boris.brezillon@bootlin.com>2018-07-18 16:44:01 +0200
commit5f7a01e222635cba7e4889ad4ebd891835e8b2eb (patch)
treeb9f17331dac2996ae44d43ce37f16ef6e2cf6da6 /CREDITS
parentjffs2: use 64-bit intermediate timestamps (diff)
downloadlinux-5f7a01e222635cba7e4889ad4ebd891835e8b2eb.tar.xz
linux-5f7a01e222635cba7e4889ad4ebd891835e8b2eb.zip
jffs2: use unsigned 32-bit timstamps consistently
Most users of jffs2 are 32-bit systems that traditionally only support timestamps using a 32-bit signed time_t, in the range from years 1902 to 2038. On 64-bit systems, jffs2 however interpreted the same timestamps as unsigned values, reading back negative times (before 1970) as times between 2038 and 2106. Now that Linux supports 64-bit inode timestamps even on 32-bit systems, let's use the second interpretation everywhere to allow jffs2 to be used on 32-bit systems beyond 2038 without a fundamental change to the inode format. This has a slight risk of regressions, when existing files with timestamps before 1970 are present in file system images and are now interpreted as future time stamps. I considered moving the wraparound point a bit, e.g. to 1960, in order to deal with timestamps that ended up on Dec 31, 1969 due to incorrect timezone handling. However, this would complicate the implementation unnecessarily, so I went with the simplest possible method of extending the timestamps. Writing files with timestamps before 1970 or after 2106 now results in those times being clamped in the file system. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Diffstat (limited to 'CREDITS')
0 files changed, 0 insertions, 0 deletions