Subject: Re: filexfer time stamps

From: Darren Moffat <[email-masked]>
Date: Fri, 12 Jan 2001 11:46:59 -0800 (PST)

------------- Begin Forwarded Message -------------

> I'm interested in the rational for including nseconds in the definition of
> nfstime4 (struct nfstime4 { int64_t seconds, uint32_t nseconds} ).  The
> reason behind this is that the SSH (secsh) IETF working group has just
> published a draft for the filexfer subsystem of SSH.  The draft currently
> uses uint32_t for storing "file times".
> 
> I suggested that the SSH filexfer draft should use the same representation
> of time as NFSv4 but that raised the issue of why the need for nsecond
> granularity for file systems.

NFS version 2 used a regular BSD-style timeval with 32-bit seconds and
32-bit milliseconds.  The milliseconds was changed to nanoseconds in
NFS version 3.  I think as a result of SVr4 switching to nanoseconds in
one of its time values.  NFS version 4 is just following in the NFS v3
tradition.  I think the only discussion we had (you can check the
mailing list archives) was over negative values for this quantity, or
whether the time field should be used to represent dates prior to
1970.

To my knowledge, there wasn't any real analysis of whether nanoseconds
was more appropriate than milliseconds for file times. You can
represent both in a 32-bit field, and it seemed to make sense to go for
the more fine-grain one, even if there weren't any OS's that could
support file times with this resolution - at some point in the future
it could have become a big deal. A field with too much resolution isn't
usually too much of a problem.

I presume the SSH proposal is just a 1 second resolution. For most
uses that's OK, but it could be a problem if you're comparing file
times to see which file was created first, e.g. it's a big deal if
you're doing a "make" :-)

------------- End Forwarded Message -------------

--
Darren J Moffat