From owner-freebsd-questions Tue Jan 3 10:15:58 1995 Return-Path: questions-owner Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id KAA22529 for questions-outgoing; Tue, 3 Jan 1995 10:15:58 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id KAA22518; Tue, 3 Jan 1995 10:15:51 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id FAA10158; Wed, 4 Jan 1995 05:11:29 +1100 Date: Wed, 4 Jan 1995 05:11:29 +1100 From: Bruce Evans Message-Id: <199501031811.FAA10158@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@cs.weber.edu Subject: Re: Why does ls report wrong creation date on symlinks? Cc: crtb@upcoming.dcrt.nih.gov, freebsd-bugs@freebsd.org, freebsd-questions@freebsd.org Sender: questions-owner@freebsd.org Precedence: bulk >> 2.3.5 ... "Updates are not done on files on read only file systems." >> >> Do you think this is badly worded enough to be optional? (It should say >> "shall not be done".) Do you think file times are allowed to changed if >> they haven't been updated? I couldn't find anything saying that. I >> wouldn't want to use an implementation that changed them. >I don't think it is optional, but one can argue that directories are >not files, in which case it's non-optional for files but implementation >defined for directories. If they are not files then it would be hard to read the timestamps on them set by creat() etc. Perhaps they only have to be files on writable file systems :-). >I personally used the non-file directory interpretation to implement >a promiscuous lookup mechanism. Because it used ioctl's, it did not >fall under the requirements of the readdir interface, even though it >returned additional per file meta data as well as ordering in a >directory along with the entries. A nice loophole that saved me a >great deal of overhead in time stamp updating (about 20%, as a matter >of fact) and halved the number of system calls I had to make (combined >lookup and stat). I have an 'ls' and a 'find' that both go about 220% >the speed of the default implementations. 8-). I think this problem should be handled by caching the access time stamps or even by storing them outside of inodes. The timestamps for all directories can be cached in a tiny amount of memory on most systems. (E.g., my 426MB usr partition has only 1932 directories so the access times could be cached in only 8K or 16K.) This memory could be written to disk very rarely (e.g., only when the fs is unmounted. POSIX doesn't require timestamps to be preserved if the system panics ;-). Bruce