From: "Ernesto A. Fernández" <ernesto.mnd.fernandez@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: y2038@lists.linaro.org, linux-kernel@vger.kernel.org,
Viacheslav Dubeyko <slava@dubeyko.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 13/16] hfs/hfsplus: use 64-bit inode timestamps
Date: Wed, 13 Nov 2019 00:53:04 -0300 [thread overview]
Message-ID: <20191113035304.GA8753@eaf> (raw)
In-Reply-To: <20191108213257.3097633-14-arnd@arndb.de>
On Fri, Nov 08, 2019 at 10:32:51PM +0100, Arnd Bergmann wrote:
> The interpretation of on-disk timestamps in HFS and HFS+ differs
> between 32-bit and 64-bit kernels at the moment. Use 64-bit timestamps
> consistently so apply the current 64-bit behavior everyhere.
>
> According to the official documentation for HFS+ [1], inode timestamps
> are supposed to cover the time range from 1904 to 2040 as originally
> used in classic MacOS.
>
> The traditional Linux usage is to convert the timestamps into an unsigned
> 32-bit number based on the Unix epoch and from there to a time_t. On
> 32-bit systems, that wraps the time from 2038 to 1902, so the last
> two years of the valid time range become garbled. On 64-bit systems,
> all times before 1970 get turned into timestamps between 2038 and 2106,
> which is more convenient but also different from the documented behavior.
>
> Looking at the Darwin sources [2], it seems that MacOS is inconsistent in
> yet another way: all timestamps are wrapped around to a 32-bit unsigned
> number when written to the disk, but when read back, all numeric values
> lower than 2082844800U are assumed to be invalid, so we cannot represent
> the times before 1970 or the times after 2040.
>
> While all implementations seem to agree on the interpretation of values
> between 1970 and 2038, they often differ on the exact range they support
> when reading back values outside of the common range:
>
> MacOS (traditional): 1904-2040
> Apple Documentation: 1904-2040
> MacOS X source comments: 1970-2040
> MacOS X source code: 1970-2038
> 32-bit Linux: 1902-2038
> 64-bit Linux: 1970-2106
> hfsfuse: 1970-2040
> hfsutils (32 bit, old libc) 1902-2038
> hfsutils (32 bit, new libc) 1970-2106
> hfsutils (64 bit) 1904-2040
> hfsplus-utils 1904-2040
> hfsexplorer 1904-2040
> 7-zip 1904-2040
>
> Out of the above, the range from 1970 to 2106 seems to be the most useful,
> as it allows using HFS and HFS+ beyond year 2038, and this matches the
> behavior that most users would see today on Linux, as few people run
> 32-bit kernels any more.
>
> Link: [1] https://developer.apple.com/library/archive/technotes/tn/tn1150.html
> Link: [2] https://opensource.apple.com/source/hfs/hfs-407.30.1/core/MacOSStubs.c.auto.html
> Link: https://lore.kernel.org/lkml/20180711224625.airwna6gzyatoowe@eaf/
> Cc: Viacheslav Dubeyko <slava@dubeyko.com>
> Suggested-by: "Ernesto A. Fernández" <ernesto.mnd.fernandez@gmail.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
Reviewed-by: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
next prev parent reply other threads:[~2019-11-13 3:53 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-08 21:32 [Cluster-devel] [PATCH 00/16] drivers: y2038 updates Arnd Bergmann
2019-11-08 21:32 ` Arnd Bergmann
2019-11-08 21:32 ` Arnd Bergmann
2019-11-08 21:32 ` Arnd Bergmann
2019-11-08 21:32 ` Arnd Bergmann
2019-11-08 21:32 ` [PATCH 01/16] staging: exfat: use prandom_u32() for i_generation Arnd Bergmann
2019-11-08 21:53 ` Valdis Klētnieks
2019-11-08 21:32 ` [PATCH 02/16] fat: " Arnd Bergmann
2019-11-08 21:32 ` [PATCH 03/16] net: sock: use __kernel_old_timespec instead of timespec Arnd Bergmann
2019-11-09 19:09 ` Deepa Dinamani
2019-11-10 0:46 ` kbuild test robot
2019-11-08 21:32 ` [Cluster-devel] [PATCH 04/16] dlm: use SO_SNDTIMEO_NEW instead of SO_SNDTIMEO_OLD Arnd Bergmann
2019-11-08 21:32 ` Arnd Bergmann
2019-11-09 19:14 ` Deepa Dinamani
2019-11-08 21:32 ` [PATCH 05/16] xtensa: ISS: avoid struct timeval Arnd Bergmann
2019-11-08 21:38 ` Max Filippov
2019-11-08 21:32 ` [PATCH 06/16] um: ubd: use 64-bit time_t where possible Arnd Bergmann
2019-11-08 21:32 ` Arnd Bergmann
2019-11-08 21:32 ` [PATCH 07/16] acct: stop using get_seconds() Arnd Bergmann
2019-11-08 21:32 ` [PATCH 08/16] tsacct: add 64-bit btime field Arnd Bergmann
2019-11-08 21:32 ` [PATCH 09/16] netfilter: nft_meta: use 64-bit time arithmetic Arnd Bergmann
2019-11-09 11:20 ` Phil Sutter
2019-11-15 22:44 ` Pablo Neira Ayuso
2019-11-08 21:32 ` [PATCH 10/16] packet: clarify timestamp overflow Arnd Bergmann
2019-11-08 21:32 ` [PATCH 11/16] quota: avoid time_t in v1_disk_dqblk definition Arnd Bergmann
2019-11-08 21:32 ` [PATCH 12/16] hostfs: pass 64-bit timestamps to/from user space Arnd Bergmann
2019-11-08 21:32 ` Arnd Bergmann
2019-11-20 20:30 ` [Y2038] " Ben Hutchings
2019-11-20 20:30 ` Ben Hutchings
2019-11-20 20:35 ` Ben Hutchings
2019-11-20 20:35 ` Ben Hutchings
2019-11-08 21:32 ` [PATCH 13/16] hfs/hfsplus: use 64-bit inode timestamps Arnd Bergmann
2019-11-13 3:53 ` Ernesto A. Fernández [this message]
2019-11-13 5:59 ` Viacheslav Dubeyko
2019-11-13 8:06 ` [Y2038] " Arnd Bergmann
2019-11-13 17:03 ` Viacheslav Dubeyko
2019-11-08 21:32 ` [PATCH 14/16] drm/msm: avoid using 'timespec' Arnd Bergmann
2019-11-08 21:32 ` Arnd Bergmann
2019-11-12 16:55 ` Jordan Crouse
2019-11-12 16:55 ` Jordan Crouse
2019-11-08 21:32 ` [PATCH 15/16] drm/etnaviv: use ktime_t for timeouts Arnd Bergmann
2019-11-08 21:32 ` Arnd Bergmann
2019-11-08 23:03 ` Lucas Stach
2019-11-08 23:03 ` Lucas Stach
2019-11-09 12:12 ` Arnd Bergmann
2019-11-09 12:12 ` Arnd Bergmann
2019-11-11 9:55 ` Lucas Stach
2019-11-11 9:55 ` Lucas Stach
2019-11-11 16:24 ` Arnd Bergmann
2019-11-11 16:24 ` Arnd Bergmann
2019-11-08 21:32 ` [PATCH 16/16] firewire: ohci: stop using get_seconds() for BUS_TIME Arnd Bergmann
2019-11-13 20:04 ` Stefan Richter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191113035304.GA8753@eaf \
--to=ernesto.mnd.fernandez@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=slava@dubeyko.com \
--cc=y2038@lists.linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.