Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Tue, 21 Aug 2001 08:36:33 +0200
From: Martin Kraemer <Martin.Kraemer@Fujitsu-Siemens.com>
To: new-httpd@apache.org
Subject: Re: file attribute questions
Message-ID: <20010821083633.A4748@deejai2.mch.fsc.net>
References: <p05101001b7a63f5119f4@[192.168.0.16]>
 <035101c1293a$60e0ed00$95c0b0d0@roweclan.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <035101c1293a$60e0ed00$95c0b0d0@roweclan.net>;
 from wrowe@rowe-clan.net on Mon, Aug 20, 2001 at 12:34:37AM -0500
Status: O

On Mon, Aug 20, 2001 at 12:34:37AM -0500, William A. Rowe, Jr. wrote:
> > * What is the difference between mtime and ctime? Also, would anybody have any use for creation date (as opposed to modification
> date)? I don't think anything outside the mac world uses creation dates.
> 
> modified versus created (I think that answers your question.)  And yes, Win32 NTFS
> and some other systems have ctime.  So does unix.

Ehmmm.... As a nonWin32 enthusiast may I please interrupt here...

It *may* be true that the windows API mis-interpreted the commonly
accepted unix semantics for what the ctime field stands. In ALL unix
systems, as well as in Linux, it stands for "time of last change to
the inode".
<sarcast>
I certainly do believe that microsoft had a hard time
to fit that into the existing DOS and Win9x world, but then hey,
the correct definition is clear.
</sarcast>

To illustrate the intricasies of "a change to the inode", let me show you
what actually happens to the three time stamps mtime, ctime, atime
when you do a set of operations on the file.

Here's a script which does that (on FreeBSD, there's a "ls -T" flag which
shows the time stamp to the second.)

--snip--
#!/bin/sh
set -x
rm -f the.file another.name
date | tee the.file
ls -Tl the.file
ls -Tlc the.file
ls -Tlu the.file
sleep 3
touch the.file
ls -Tl the.file
ls -Tlc the.file
ls -Tlu the.file
sleep 3
ln the.file another.name
ls -Tl the.file
ls -Tlc the.file
ls -Tlu the.file
sleep 3
cat another.name
ls -Tl the.file
ls -Tlc the.file
ls -Tlu the.file
sleep 3
date >>another.name
ls -Tl the.file
ls -Tlc the.file
ls -Tlu the.file
--snip--

And here's the output:
---start---
+ rm -f the.file another.name
+ date
+ tee the.file
Di  21 Aug 2001 08:26:34 CEST
+ ls -Tl the.file
-rw-r-----  1 martin  kraemer  30 21 Aug 08:26:34 2001 the.file
+ ls -Tlc the.file
-rw-r-----  1 martin  kraemer  30 21 Aug 08:26:34 2001 the.file
+ ls -Tlu the.file
-rw-r-----  1 martin  kraemer  30 21 Aug 08:26:34 2001 the.file
+ sleep 3
+ touch the.file
+ ls -Tl the.file
-rw-r-----  1 martin  kraemer  30 21 Aug 08:26:37 2001 the.file
+ ls -Tlc the.file
-rw-r-----  1 martin  kraemer  30 21 Aug 08:26:37 2001 the.file
+ ls -Tlu the.file
-rw-r-----  1 martin  kraemer  30 21 Aug 08:26:37 2001 the.file
+ sleep 3
+ ln the.file another.name
+ ls -Tl the.file
-rw-r-----  2 martin  kraemer  30 21 Aug 08:26:37 2001 the.file
+ ls -Tlc the.file
-rw-r-----  2 martin  kraemer  30 21 Aug 08:26:40 2001 the.file
+ ls -Tlu the.file
-rw-r-----  2 martin  kraemer  30 21 Aug 08:26:37 2001 the.file
+ sleep 3
+ cat another.name
Di  21 Aug 2001 08:26:34 CEST
+ ls -Tl the.file
-rw-r-----  2 martin  kraemer  30 21 Aug 08:26:37 2001 the.file
+ ls -Tlc the.file
-rw-r-----  2 martin  kraemer  30 21 Aug 08:26:40 2001 the.file
+ ls -Tlu the.file
-rw-r-----  2 martin  kraemer  30 21 Aug 08:26:43 2001 the.file
+ sleep 3
+ date
+ ls -Tl the.file
-rw-r-----  2 martin  kraemer  60 21 Aug 08:26:46 2001 the.file
+ ls -Tlc the.file
-rw-r-----  2 martin  kraemer  60 21 Aug 08:26:46 2001 the.file
+ ls -Tlu the.file
-rw-r-----  2 martin  kraemer  60 21 Aug 08:26:43 2001 the.file
---end---

Explanation:
* date | tee  -> the file is created and filled with its creation time.
  (...three seconds later):
* touch: the mtime field is updated to the current time (note that
  this also updates atime & ctime).
  (...three seconds later):
* a hard link is created from the file (so to speak, an alias name is
  created). Because the "link count" in the inode increases from 1 to 2,
  this means that a "change to the inode" occurred, and it changes the
  ctime (and the ctime ONLY). 
  At this point, people who implement or interpret "ctime" as "creation
  time" will have a hard time explaining why the.file was created NOW,
  but last modified THREE SECONDS AGO....
  Note that the two files the.file and another.name share the same inode,
  it exists only once. All file operations on another.name which modify the
  inode will be visible for the.file as well.
  (...another three seconds later):
* cat accesses the file under its alias name another.name (this access
  is identical, in all respects, to an access of the original the.file;
  the file's contents is its creation time stamp), so the atime field
  is updated. We now have three different times on the file.
  (...another three seconds later):
* date appends to "another.name" (again, this access is identical, in
  all respects, to an append to the original the.file). Note that the
  mtime changed (of course, because we made a modification NOW), but
  also the ctime changed (because the byte count of the file is an
  information stored in the inode, so the inode changed), but the
  access time, atime, did NOT change.

Luckily there are VERY few programs which rely on the correct implementation
of the semantics of the ctime field.

Hope this helps to clarify things,

   Martin
-- 
<Martin.Kraemer@Fujitsu-Siemens.com>    |       Fujitsu Siemens
       <martin@apache.org>              |   81730  Munich,  Germany