RFS and 2038
chrisj at rtems.org
Thu May 27 02:58:29 UTC 2021
On 1/5/21 6:19 am, Joel Sherrill wrote:
> Ryan has been working to add support for the new (not obsolete) nanosecond
> granularity variants of utime. In changing the utime_h file system handler to
> utimens_h and propagating the changes, Ryan tripped across this.
> rtems/rfs/rtems-rfs-inode.h:typedef uint32_t rtems_rfs_time;
> Our first inclination was to change this to time_t but I remembered that time_t
> was 64-bits and that changing this could ripple to on-media structures.
> Ignoring that there is no sub-second granularity on the utime family of
> timestamps for the RFS (and other filesystems), how can this year 2038 problem
> be addressed?
> I am pretty sure a ticket is needed but I wanted to discuss this and understand
> the scope.
> We may also have similar issues in other file systems that we didn't spot.
Did this get resolved?
(still under his rock)
More information about the devel