Subject: ctime vs. Create Time

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 7 Oct 2002 07:31:30 -0600

Hi all,

In the 'draft-draft' version of the sftp draft, 
I added a ctime field.  Then, in the course of
some other work I was doing, I actually looked
at what the ctime field meant.

Here is the text describing both the ctime and
mtime fields from the linux man page:

       The  field st_mtime is changed by file modifications, e.g.
       by mknod(2), truncate(2), utime(2) and write(2)  (of  more
       than  zero  bytes).   Moreover, st_mtime of a directory is
       changed by the creation  or  deletion  of  files  in  that
       directory.   The st_mtime field is not changed for changes
       in owner, group, hard link count, or mode.

       The field st_ctime is changed by  writing  or  by  setting
       inode  information  (i.e., owner, group, link count, mode,
       etc.).

Now, thats not what I thought at all!  I thought the 'c' in
ctime stood for create.  (You may even notice that in the
paragraph describing 'atime', 'ctime', and 'mtime', I said
that ctime was 'creation' time.

Under windows, the creation time of a file is stored, and I
was looking for the ability to perserve that value.

So, in my working copy I've changed ctime into 'createtime'.

I'm not sure I see a need for both mtime and ctime. Do people
think we need both?

What do people think about create time?

- Joseph

---

From: "Dan O'Reilly" <[email-masked]>
Date: Mon, 07 Oct 2002 07:40:56 -0600

I would much prefer that both creation and modification times be preserved.
If we're talking about copying a file intact between systems, inevitably,
there will be somebody who will have that requirement.  If the field is
common (or at least reasonably so), I always vote to preserve it if at all
possible.

For example, in VMS there are even more time fields kept for a file, although
I don't expect this standard to address those (unless you're feeling
particularly amicable today <grin>).

>What do people think about create time?

------
+-------------------------------+----------------------------------------+
| Dan O'Reilly                  |  "There are 10 types of people in this |
| Principal Engineer            |   world: those who understand binary   |
| Process Software              |   and those who don't."                |
| http://www.process.com        |                                        |
+-------------------------------+----------------------------------------+

---

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 7 Oct 2002 07:50:33 -0600

> particularly amicable today <grin>).

Well, I might be :-)

I don't remember what they are though; my VMS experience is
about 10 years ago, so it is growing dimmer and dimmer.
I was trying to remember if VMS did create time and thought
that it did.  What other time fields does VMS keep?

Do you think the draft should address them?  Do you think
they are useful, even if not generally implementable?

- Joseph

---

From: "Dan O'Reilly" <[email-masked]>
Date: Mon, 07 Oct 2002 07:59:18 -0600

>that it did.  What other time fields does VMS keep?

If memory serves (I'm not near a VMS system at this point), there is a
backup date and a "shelving" date (when the file was copied to other media,
not as a backup).  I don't know that either would be of any specific value
to keep, however, as those are pretty much specific within the context of
an individual system, and I would think they would tend to lose meaning
when copied to another system.

------

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 07 Oct 2002 13:15:58 -0400

unix doesn't have a concept of "creation time".  within the posix
"stat" API, "ctime" is the "last metadata change" time whereas "mtime"
is "last contents change"; "atime" is "last access time".

Note that update of atimes is commonly disabled for performance
reasons.

If you are aiming for "least common denominator", the best you can do
is a single timestamp for the mtime value.

If you are aiming for "model every known filesystem feature relating
to dates", then we'll be here for a while...

					- Bill

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 7 Oct 2002 13:31:00 -0400

IMHO, we ought to be designing any file times with specific reference
to the IEEE POSIX.1 standard && we should avoid creating a new file 
timestamp
definition having semantics different from each of the POSIX timestamp
definitions.

On Monday, Oct 7, 2002, at 13:15 America/Montreal, Bill Sommerfeld

---

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 7 Oct 2002 12:05:43 -0600

> to dates", then we'll be here for a while...

What I'm really aiming for is "model the most commonly available
and used filesystem features relating to dates."

Both Windows and VMS store creation dates.  Windows and unix
optionally store acces time, but it is commonly disabled for
performance.  (I think VMS also can record access time,
but usually does not.)

So I would argue that Creation time is part of the
"medium common denominator"

What I wasn't sure of is if "metadata change" as
seperate from "content change" is interesting.

Windows does not track that data. I don't know if VMS
does.  I don't know if people use that data when operating
on files.

- Joseph

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 7 Oct 2002 15:12:38 -0400

On Monday, Oct 7, 2002, at 14:05 America/Montreal, Joseph Galbraith 
> 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.

> performance.  (I think VMS also can record access time,

UNIX does not commonly disable access time.  Windows varies
with which flavour of which version of which kind of Windows
one has.  As noted above, in an IETF standards context the
right target is to be compliant with (one of the) POSIX.1 timestamps.

Ran

---

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 7 Oct 2002 14:21:09 -0600

> 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