Hi: On Tue, Jul 10, 2018 at 11:40:50PM +0200, Arnd Bergmann wrote: > 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 > > This changes Linux over to mostly the same behavior as described in the > code comment in MacOS X, disallowing all times before 1970 and after > 2040, while still allowing times between 2038 and 2040 like most other > implementations do. Most importantly, it means we can have the same > behavior on 32-bit and 64-bit. > > Cc: stable@xxxxxxxxxxxxxxx > 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 > Suggested-by: Viacheslav Dubeyko <slava@xxxxxxxxxxx> > Signed-off-by: Arnd Bergmann <arnd@xxxxxxxx> > --- > v2: treat pre-1970 dates as invalid following MacOS X behavior, > reword and expand changelog text > --- > fs/hfs/hfs_fs.h | 29 +++++++++++++++++++++++++---- > fs/hfsplus/hfsplus_fs.h | 26 +++++++++++++++++++++++--- > 2 files changed, 48 insertions(+), 7 deletions(-) > > diff --git a/fs/hfs/hfs_fs.h b/fs/hfs/hfs_fs.h > index 6d0783e2e276..1af998fb522e 100644 > --- a/fs/hfs/hfs_fs.h > +++ b/fs/hfs/hfs_fs.h > @@ -246,14 +246,35 @@ extern void hfs_mark_mdb_dirty(struct super_block *sb); > * mac: unsigned big-endian since 00:00 GMT, Jan. 1, 1904 > * > */ > -#define __hfs_u_to_mtime(sec) cpu_to_be32(sec + 2082844800U - sys_tz.tz_minuteswest * 60) > -#define __hfs_m_to_utime(sec) (be32_to_cpu(sec) - 2082844800U + sys_tz.tz_minuteswest * 60) > +static inline time64_t __hfs_m_to_utime(__be32 mt) > +{ > + time64_t ut = (u32)(be32_to_cpu(mt) - 2082844800U); > + > + /* > + * Times past 2040-02-06 06:28 are assumed to be invalid, > + * matching the MacOS behavior. > + */ > + if (ut > 2082844800U + UINT_MAX) I'm not sure what you were going for here, but this isn't right. Times as early as 2036 will be considered invalid. > + ut = 0; > + > + return ut + sys_tz.tz_minuteswest * 60; > +} > > +static inline __be32 __hfs_u_to_mtime(time64_t ut) > +{ > + ut -= - sys_tz.tz_minuteswest * 60; ^^^^^ An extra minus. > + > + /* > + * MacOS wraps "invalid" times after 2040 when writing back, so > + * let's do the same here. > + */ > + return cpu_to_be32(lower_32_bits(ut + 2082844800U)); > +} > #define HFS_I(inode) (container_of(inode, struct hfs_inode_info, vfs_inode)) > #define HFS_SB(sb) ((struct hfs_sb_info *)(sb)->s_fs_info) > > -#define hfs_m_to_utime(time) (struct timespec){ .tv_sec = __hfs_m_to_utime(time) } > -#define hfs_u_to_mtime(time) __hfs_u_to_mtime((time).tv_sec) > +#define hfs_m_to_utime(time) (struct timespec){ .tv_sec = __hfs_m_to_utime(time) } > +#define hfs_u_to_mtime(time) __hfs_u_to_mtime((time).tv_sec) Are the new spaces intentional? > #define hfs_mtime() __hfs_u_to_mtime(get_seconds()) > > static inline const char *hfs_mdb_name(struct super_block *sb) > diff --git a/fs/hfsplus/hfsplus_fs.h b/fs/hfsplus/hfsplus_fs.h > index d9255abafb81..7f0943e540a0 100644 > --- a/fs/hfsplus/hfsplus_fs.h > +++ b/fs/hfsplus/hfsplus_fs.h > @@ -530,9 +530,29 @@ int hfsplus_submit_bio(struct super_block *sb, sector_t sector, void *buf, > void **data, int op, int op_flags); > int hfsplus_read_wrapper(struct super_block *sb); > > -/* time macros */ > -#define __hfsp_mt2ut(t) (be32_to_cpu(t) - 2082844800U) > -#define __hfsp_ut2mt(t) (cpu_to_be32(t + 2082844800U)) > +/* time helpers */ > +static inline time64_t __hfsp_mt2ut(__be32 mt) > +{ > + time64_t ut = (u32)(be32_to_cpu(mt) - 2082844800U); > + > + /* > + * Times past 2040-02-06 06:28 are assumed to be invalid, > + * matching the MacOS behavior. > + */ > + if (ut > 2082844800U + UINT_MAX) Same as before, 2036-2040 will be invalid. For the record, your original solution (supporting the 1970-2106 range) still makes more sense to me. It seems Apple is not using the 1904-1970 range for anything; if they are still supporting hfsplus by the 2030s I assume they will deal with this in a similar way. Thanks, Ernest > + ut = 0; > + > + return ut; > +} > + > +static inline __be32 __hfsp_ut2mt(time64_t ut) > +{ > + /* > + * MacOS wraps "invalid" times after 2040 when writing back, so > + * let's do the same here. > + */ > + return cpu_to_be32(lower_32_bits(ut + 2082844800U)); > +} > > /* compatibility */ > #define hfsp_mt2ut(t) (struct timespec){ .tv_sec = __hfsp_mt2ut(t) } > -- > 2.9.0 >
