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) _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
