From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <442D09D7.1070709@proweb.co.uk> Date: Fri, 31 Mar 2006 11:52:07 +0100 From: matt User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Re: patch/list sorry/proc-mtime References: <22bde5614000d885106987413c69bb88@swtch.com> In-Reply-To: <22bde5614000d885106987413c69bb88@swtch.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Topicbox-Message-UUID: 2a189094-ead1-11e9-9d60-3106f5b1d025 > Maybe in someone else's humble opinion the modification time > (there is no creation time in Plan 9) of /proc should be the time of > the last call to fork or exits, i.e. the last time the directory actually > changed. There isn't an obvious value here. > > Overloading mtime for all these purposes > is misguided, as none of them are actually modification times. Sure, I don't disagree that there are any number of "good" values one could pop into the mtime & atime. That's the point of discussing it, "what do people think should go in the mtime & atime" On FreeBSD they are both the current system time for /proc My thoughts, but no action, on the subject is that it is perhaps the concept of mtime and atime that are wrong. They seem to be terms welded to a disk based system. If there are plenty of values that *could* be available, shouldn't we be open to finding a way to expose them ?