RFS and 2038

[Joel Sherrill]

On Wed, May 26, 2021, 9:58 PM Chris Johns <chrisj at rtems.org> wrote:

> 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?
>

No. The API additions required a minor header file change in newlib. I
bumped the RSB for this. There is a patch for RTEMS, libbsd, and legacy net
to switch the filesystem utime handler to the nanosecond signature.

I've been letting the RSB patch be committed a bit before pushing the
others since it is a break.


> Chris
>   (still under his rock)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210527/688ed78a/attachment.html>