I am still trying to nail down the why rather than the what of Thompson's 
design.  In The UNIX Time-Sharing System, a paper written by Ritchie and 
Thompson, dated April 3, 1978 and published in The Bell System Technical 
Journal, vol 57, No 6, July-August 1978, pg 1914, there is the following 
quotation:

The entry found thereby (the file's i-node) contains the descriptions of 
the file:
  (i) the user and group-ID of its owner
(ii) its protection bits
(iii) the physical disk or tape addresses for the file contents
(iv) its size
  (v) time of creation, last use, and last modification
(vi) the number of links to the file, that is, the number of times it 
appears in a directory
(vii) a code indicating whether the file is a directory, an ordinary file, 
or a special file.

Clearly, from Thompson's choice of words, he too thought creation time was 
significant.  What follows in the paper is a high level discussion of the 
file system, the i/o system and the uniquely UNIX notion of the delayed 
write.  They do not discuss any of this at a low enough level to know why 
they chose not to retain creation date as a permanent property of the file 
inode on disk.

By 1986 in Bach this seems to be taken for granted.  Bach discusses using 
pseudo code the important algorithms in the UNIX kernel including the 
allocation and management of inodes.  The UNIX he wrote about was AT&T 
System V.  If he discusses why creation time is volatile over the life of 
the file, I have not yet found it.

So, at this point we can't say for sure whether Thompson made a mistake.  I 
think not but I am biased in his favor from 25 years living with 
UNIX.  Just as Linux began life as the genius of one person, so too did 
UNIX.  I have always assumed in my study of early UNIX that resources were 
much scarcer back then, then they are today, and this was a simple 
time-space trade off.  The hardware they were writing about in that paper 
was the 16 bit DEC PDP-11/70 with 768KB of memory and two, 200MB 
disks.  The kernel was 90KB.  The authors state in the paper that this UNIX 
they were describing could run in a memory space as small as 96KB.  Every 
system has some physical limits that are reflected in design trade offs and 
my inference, in the absence of something definitive to the contrary, is 
that ctime was overwritten because Thompson could not afford not to.  To 
those who came later, these trade-offs some times appear to be arbitrary, 
and perhaps stupid.  I would bite my tongue before I made such an assertion 
about UNIX.

Will

At 02:45 PM 9/30/2004 -0400, Mark Mielke wrote:
> You might want to read up on why st_ctime is *not* creation time. Either
> your book is wrong, or it says more than you think. :-)
> 
> mark
> 
> 
> On Thu, Sep 30, 2004 at 12:35:23PM -0400, Jerry wrote:
>  > According to Unix Internals, Steve D. Pata, 1996, A-D, *creation* time 
>  is a function of the FileSystem Stat structure (FS_STATF ( )). The basic 
>  inode fields that describe the more commonly known properties of a file are:
>  >
>  > i_number        the filesystem dependent inode number of the file
>  > i_ftype             the type of inode (regular file, directory, pipe, etc.)
>  > i_size               the size of the file in bytes
>  > i_uid                 the file's owner
>  > i_gid                 the file's group
>  > i_nlink              number of hard links to the file
>  > i_rdev              device number used for raw I/O
>  > i_dev               the device where the inode resides.
>  >
>  > >From this structure, the inode structure is linked into the stat 
>  structure, where you will find *atime*, *mtime*, and *ctime*. These are 
>  represented in the FS_STAT( ) structure as st_atime, st_mtime, and 
>  st_ctime within the stat structure. As far as inodes go, when a file is 
>  being accessed, it is represented in memory by an in-core inode defined 
>  by the inode structure (or inode_t). The fields of the inode are 
>  identical for each file regardless of the underlying physical file it 
>  represents. For open files, the inode is pointed by one or more file 
>  structures. However, file structures, for which there may be multiple 
>  entries for accessing the same physical file, there is only one inode 
>  entry representing the file.
>  >
>  > As for whether you need to *look* at a file or not is not a concern of 
>  the OS, as files are executed, the file you are looking at may be swapped 
>  out by a file of higher priority. As previously mentioned, c_time is kept 
>  in the FS_STAT( ) structure. If you look at sys/fstyp.h, it will show you 
>  the macros available for accessing these structures, for FS_STAT( ) the 
>  function name is statf.
>  >
>  > I highly recommend this book for anyone working on kernel related material.
>  >
>  > Jerry Simons
>  >
>  > Sn. Systems Analyst - Alset Technologies
>  >
>  > CONFIDENTIALITY WARNING:
>  > This electronic message contains information which may be privileged 
>  and/or confidential. This information is intended for the exclusive use 
>  of the individual(s), entity, or persons named or indicated above. Any 
>  unauthorized access, disclosure, copying, distribution, or use of any 
>  parts of the contents of this message/information is strictly prohibited 
>  by federal law. Any attempts to intercept this message are in violation 
>  of Title 18 U.S.C. 2511(1) and/or Section(s) 3121-3127 of the Electronic 
>  Communications Privacy Act (ECPA). All violators are subject to fines, 
>  imprisonment or civil damages, or both.
>  >
>  >   ----- Original Message -----
>  >   From: Mark Mielke
>  >   To: T. William Schmidt
>  >   Cc: intertwingled@[...].net ; Martin Leese ; 
>  activeperl@[...].com
>  >   Sent: Tuesday, September 28, 2004 16:14
>  >   Subject: Re: ls dates vs. stat() ages
>  >
>  >
>  >   On Tue, Sep 28, 2004 at 12:54:31PM -0700, T. William Schmidt wrote:
>  >   > From The Design of the UNIX Operating System, Bach, 1986, P-H, an 
>  inode in
>  >   > memory is 64 bytes.  UNIX uses linked lists of inodes in file access
>  >   > algorithms.  There is no room in 64 bytes for another date, and 
>  creation
>  >   > date, as opposed to modification date has no added value.  Carrying 
>  around
>  >   > 4 extra bytes means at least 7% fewer inodes can be in memory at 
>  any given
>  >   > time for a given amount of memory.  The inode modification time 
>  stamp is
>  >   > equally relevant as a measure of relative staleness.  Remember, to
>  >   > manipulate a file system effectively an OS must maintain in-memory 
>  data
>  >   > structures.  Ken Thompson put into inodes what was important and 
>  left out
>  >   > what was irrelevant for performance.
>  >
>  >   Usually, "staleness" is a measure of *access* time, not *modification*
>  >   time, when considered in terms of cachable data structures. Who cares if
>  >   the file or inode was last modified a year ago? Whether it should be in
>  >   memory should be based on whether I've needed to *look* at it before.
>  >
>  >   The explanation offered is only valid if one assumes that the people
>  >   at the time didn't understand good cache design. I would like to think
>  >   that this assumption is false.
>  >
>  >   Also, creation time could be kept in a separate data structure that is
>  >   more expensive to query, so the whole subject of whether it fits in some
>  >   arbitrary 64 byte structure is irrelevant. What is relevant, is that they
>  >   didn't decide to do it.
>  >
>  >   I would think (guess!) that the real reason is that they either 
>  forgot, or
>  >   they just couldn't come up with a good reason why somebody would want the
>  >   creation time.
>  >
>  >   mark
>  >
>  >   --
>  >   mark@mielke.cc/markm@ncf.ca/markm@[...].com 
>  __________________________
>  >   .  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
>  >   |\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   |
>  >   |  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, 
>  Ontario, Canada
>  >
>  >     One ring to rule them all, one ring to find them, one ring to bring 
>  them all
>  >                          and in the darkness bind them...
>  >
>  >                              http://mark.mielke.cc/
>  >
>  >   _______________________________________________
>  >   ActivePerl mailing list
>  >   ActivePerl@[...].com
>  >   To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
> 
> --
> mark@mielke.cc/markm@ncf.ca/markm@[...].com 
> __________________________
> .  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
> |\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   |
> |  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
> 
>    One ring to rule them all, one ring to find them, one ring to bring 
>  them all
>                         and in the darkness bind them...
> 
>                             http://mark.mielke.cc/

Regards,
Will Schmidt

WilliamSchmidt.com, LLC
11201 NW 77th Street
Terrebonne, OR  97760
541 504-0290
will@[...].com
http://www.williamschmidt.com/

_______________________________________________
ActivePerl mailing list
ActivePerl@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs