RFS and 2038

[Chris Johns]

On 1/5/21 6:19 am, Joel Sherrill wrote:
> Hi
> 
> 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?

Chris
  (still under his rock)