From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <7ace5eae935a5132ddb514b35b67539e@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 22 Jan 2009 13:08:37 -0500
To: lucio@proxima.alt.za, 9fans@9fans.net
In-Reply-To: <6ad3bbac8db808921b373026762db2e6@proxima.alt.za>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Subject: Re: [9fans] file creation time
Topicbox-Message-UUID: 8451ab7e-ead4-11e9-9d60-3106f5b1d025

On Thu Jan 22 12:54:14 EST 2009, lucio@proxima.alt.za wrote:
> > use the dump, luke. ☺
>
> If there was an easy, foolproof way to scan the dump by filename, I
> presume I could search for the earliest instance and consider that the
> time of creation.  Not entirely viable, is it?

it's hard to give a good answer, since i don't
know what the goal is.

> I do wonder why this field was sacrificed in the file system(s) and
> 9P*?
>
> Or am I dreaming and the time of creation is just a figment of my
> imagination?

of course on a worm filesystem, you could say that each
time a file is modified after it has made it to the worm, it
becomes a brand new file.  though the qid.path doesn't
track this view.  the create time would then differ
from the mtime by as most the time between dumps.

andrey suggests

> history(1)

history doesn't give creation times.  it gives the last mtime
before the first dump of the file.  the file could be deleted
and recreated many times and you'd never know.  (unless
you were to peek at the qid.path.)

but then again, history might be exactly what you're
looking for.  it usually is for me.

- erik