Re: ctime vs. Create Time

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

> On Monday, Oct 7, 2002, at 14:05 America/Montreal, Joseph Galbraith 
> wrote:
> > What I'm really aiming for is "model the most commonly available
> > and used filesystem features relating to dates."
> 
> The right target is to be consistent with other IETF standards
> (e.g. NFS).  Those standards are based upon POSIX.1 timestamps,
> not proprietary (e.g. Microsoft, VMS) timestamps.


I agree that being consistent with other IETF standards
is a good goal.  I've actually looked at NFS several times
and borrowed from it where appropriate.

NFS defines the following time fields as recommended
attributes (RFC 3010):

time_access
time_backup
time_create
time_metadata (unix ctime)
time_modify

In fact, reviewing NFS with regard to time values, I think
we should change our time values to be uint64.  I'd rather
not go out the door with a 2038 (or whenever) bug.  I'll be
retired (maybe), but I know people who won't be :-)

The create time is also defined by FTP MLST extensions.  Access
time is not; I'd be willing to remove access time before create
time-- a Windows user can added the create time to their file
listing view with two mouse clicks -- access time doesn't appear
to be exposed in the UI.

But I think we should keep all three.

The people who are actually doing VMS (where there is a backup
time) didn't seem to think it needed to be in the protocol.
Though now that they know it is in NFS, maybe they are
changing their minds :-)

I think people doing unix implementations should say whether or
not they want a time_metadata.  To my mind, they are the ones
that have to live with the consequences of such a decision, and
they are the ones that have to deal with customers that may or
may not be concerned over the preservation of that file attribute.

The thing I think I've been hearing is that they don't need to
preserve this time stamp.

- Joseph