> I am not sure about this. Static devices having all the > same mtime (kerndate) makes sense to me. Dynamic > devices in which files and directories appear and disappear > as draw or proc not having the mtime set as normal > dir/files doesnt.
In all fairness at least the semantics for files inside each proc directory would not match directly what one would expect from static file systems (eg., content can change, but mtime would always be the creation time of the proc.) Maybe setting only the mtime of the dirs would removes any ambiguity. Certainly having dirs with a mtime that clearly predates their creation is far from ideal. > It may be done for simplicity, > but it breaks what one would expect. The information > is not duplicated as far as I understand. The info on the > mtime would be when the process started, but the > info inside status is how much time it has consumed > isnt it?. The information in status also includes real elapsed time in ms, that can be used to calculate when the process started as russ pointed out. Still this is tedious and akward and the mtime of the proc dirs seems like a natural place to present this often useful information. Adding the calculation to ps is another possibility, but IMHO it would unnecessarily clutter the output, probably add an extra option and require more code while ls -lt /proc works just fine with the mtime approach. In the end everything is matter of convenience and taste, but this criticism comming from the person that instigated the tar -z abomination is harder to take seriously. > All this said, I am not coding any of this, so I have voice but not vote... FYI here is the change to set the mtime, a single line of code: + dp->mtime = seconds() - TK2MS(MACHP(0)->ticks - p->time[TReal]) / 1000; uriel
