Re: creation time of a file?

> I know that the Unix faq says that the creation time is not stored.
>  http://www.faqs.org/faqs/unix-faq/faq/part3/section-1.html

As that page points out, I think what happened is that many people confused
"ctime" with "creation time", especially since the descriptions
"modified time" and "changed time" just don't lend themselves to being
kept apart.

> But I see that
> http://www.dickinson.edu/~braught/courses/cs354f97/Classes/ ...
> mentions a creation time in a 4.4 BSD Unix I-Node and also says a
> "generation number" field is based on the creation time of the file.

This would not be the first time that a professor has been mistaken.

> Did the creation time used to be stored?

No.

> Is there a "generation number"? And if so can the creation time of a file
> be figured out from it?

The generation number is a gimmick which was added to the FFS filesystem
in order to solve a problem with NFS:  if an NFS file identifier is the
<filesystem,inode-number> of the inode, then you run into the situation
where a client with an open file handle can continue reading a file after
the file is closed, deleted, and re-created as a brand-new (and unrelated)
file.  So they added the "generation number", which started at 1 on a brand
new filesystem and was incremented by 1 every time a file was recycled,
thus allowing the file handle to be 
<filesystem,inode-number,generation-number>.  It was then observed that this
is a glaring security hole, since all three of those numbers are easy to
guess.  That led to the fsirand utility which goes and stirs up all the
generation numbers on disk (setting them to random numbers); it looks
like the NetBSD code still increments the number, so it is probably still
possible to modify a known filehandle to go fishing with it, but at least
the initial randomization means you can't go fishing for arbitrary inode
numbers.  (A quick web search revealed a linux-related page claiming the
generation number changes "unpredictably"; I don't know if they've gone
to the effort of randomizing every time the delete a file, or if they
just have issues with addition. :-) )  In any case, I don't think the
creation time would have ever been a good generation number, since (a)
on a sufficiently fast system an inode might get recycled multiple times
a second, and (b) it's predictable, leading to fishing expeditions.