RFS and 2038

[Joel Sherrill]

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.

--joel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210430/355260c9/attachment.html>