Why does "file" change the creation time on some Unix systems?

[Guy Harris]

>The "file" command on our NCR Tower 32/600 (version 1.04.02) and on
>our Motorola 8650 changes the creation time of the files it examines.

If what you say is completely true, you must be running a pretty bizarre
version of UNIX; no version I know of maintains the *creation* time of a
file. 

Now, most versions I know of maintain the time the inode was last
changed; this is often called the "ctime", and people often make a huge
and bogus leap and assume that the "c" stands for "creation".

So, we'll assume you're running a fairly ordinary version of UNIX, and
that you meant "(inode) change time" rather than "creation time"....

>The file command doesn't do that on some of our other Unix systems
>(Microport 286, Interactive 386). Is there any reason (other than
>brain damage) why "file" should change the creation time?

"file" generally has to read a file to figure out what type of file it
is.  Normally, this would cause the access time of the file to be
updated.  The S5 version of "file" dutifully tries to pretend that it
*didn't* read the file, and does a "utime" call to reset the access time
to its pre-read value. 

This causes the inode change time to be modified, to flag the fact that,
well, the inode was changed by the "utime" call.  This call only works
if you're super-user or own the file.  The reason why it doesn't happen
on your Microport or Interactive system is probably one of:

	1) they took the "reset-the-access-time" hack out of "file";

	2) you didn't own the file on the other systems, but did own it
	   on the Tower;

	3) you didn't do it as super-user on the other systems, but did
	   on the Tower;

	4) "file" is set-UID "root" on the Tower;

	5) other.

I don't know that there's a compelling reason why "file" should reset
the access time, other than "well, it does that as shipped by AT&T, and
we don't want to change it"; whether this is "compelling" or not depends
on how important vanillitude of your UNIX is to you.