Date:        Wed, 22 Nov 2000 14:47:53 -0500
    From:        "Steven M. Bellovin" <smb@research.att.com>
    Message-ID:  <20001122194754.4195935DC2@smb.research.att.com>

  | In message <20001122113556.K578@goldberry.poofy.goof.com>, "Aaron J. Grier" wri
  | tes:

For some reason I didn't see the original of this message (or I
skipped over it reading quickly ..) so I am replying to Steve's reply,
though I have no comments about what he said, which is all true.

  | >any time a new (as in, not previously existing) file name (including
  | >pathname to the root of the mount point) is introduced on a file system,
  | >attach to that filename a time.

For what conceivable use?   Do you intend it to remain constant no matter
what happens to the contents of the file?  That is, if I use /tmp/foo
as my standard place to put stdout (and maybe stderr) of long running
commands, so the filename was created a couple of months ago, but the file
data has been totally replaced with 40 different (totally unrelated)
contents in the meantime, what possible use is it to anyone to know
when it was that I first used the name?   (since the last reboot anyway
when /tmp was cleared).

And this is quite apart from the difficulty of attaching a time to an
element of a directory (it could be done by changing the directory
structure - that has been done before - but it is a HUGE change).

  | >one could argue that the other time stamps are just as arbitrary and
  | >meaningless.

You could try, but it would be a pretty difficult argument to win.
mtime tells when the data in the file was last altered - which is useful
if something else depends upon that, so it can also be updated (this is
how make works), or just to know that a process is continually updating
its output.   atime tells when the data of a file was last accessed, which
is useful to know when mail was last read, to know that a security scan
actually happened when it should, or to see that no-one has been reading
a file that you don't expect to be touched.  ctime tells when anything
material related to a file was changed, which is needed to know that the
file needs to be dumped (if the ctime is more recent than the last dump).

  | >all you have to do is strictly define the behaviour, and
  | >it ceases to be arbitrary.

That's a strange definition of arbitrary.   But yes, you could strictly
define the behaviour, and it would then be defined (still most likely
arbitrary).

  | >whether or not it is useless depends on
  | >whether or not you find utility with it.

True - but I am still waiting for a rational use to which this data
could be put.

  | >having a creation time as defined above answers the question "how long
  | >has that filename existed in the filesystem?"

And why would anyone want to know that?

If I do
	command > /tmp/foo
	other-command > /tmp/foo

then the creation time (by your definition) will be that when command
was executed.

On the other hand, if I do

	command > /tmp/foo
	rm /tmp/foo
	other-command > /tmp/foo

it will be the time when other-command was executed.   Yet it is the
same name, ends with the same contents, ...   What rationale is there
for the difference?

If you want to keep track of the history of a file, use a tool designed
for the purpose, sccs, rcs, cvs ...   They will record when the thing
was first created (when it was first given to the tool to look after)
and then when (and what) changes happened after that.

kre

ps: if the difference between inodes and directories is not clear, take
a look at either of the BSD books (McKusick et-al) - doesn't matter for
this if you peruse the 4.3 or 4.4 edition.  Note the way that the filesystem
tree is drawn.

Compare that with your average unix book, which does something like
(usually using circles instead of rectangles, but circles are beyond
my ascii-art competence):

                              ------
                              |  / |
                              ------
                       /    /   |   \      \
                      /    /    |    \      \
                ------  -----  -----  -----  -------
                | bin|  |etc|  |dev|  |usr|  | var |
                ------  -----  -----  -----  -------
                 /   \
              -----  -----
              | ls|  | cp|
              -----  -----

etc.   WHenever you see that, you know the author of the book (or whatever)
doesn't understand the unix filesystem at all (unless, just rarely, they
do that for a simplified view, and then explain what it is really like).