Date: Tue, 3 Jan 95 10:23:44 MST From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, crtb@upcoming.dcrt.nih.gov, freebsd-bugs@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Why does ls report wrong creation date on symlinks? Message-ID: <9501031723.AA04465@cs.weber.edu> In-Reply-To: <199501030348.OAA25660@godzilla.zeta.org.au> from "Bruce Evans" at Jan 3, 95 02:48:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> >POSIX leaves a loophole, allowing read-only media to ignore the > >> >update requirements -- so you can be technically compliant if you > >> >mount the disk read-only. Very useful. 8-). > >> > >> Pretending that directories were modified at the current time breaks > >> even this :-). > > >Actually, no it doesn't. > > >POSIX doesn't require the information be accurate. > > >POSIX only required that the information be updated in certain > >circumstances. > > 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. I think that, in particular was worded badly enough to include VMS 5.x and above as conforming (in VMS a directory *isn't* a file). There's nothing saying that they "shall not be marked for update except...", so I think that randomly updating the time is acceptable (if in clear violation of the rule of least astonishment) and within the bounds of a conforming file system. The question is not whether the behaviour is allowed, but whether it is specifically disallowed. I probably wouldn't want to use an FS that stretched all of the semantic bounds it could possibly stretch (although it might be fun to write one for the hell of it 8^). As an editorial comment on the standard, if nothing else). 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-). Actually, you'd want to optionally return the stat information for a file on nearly any directory operation... stat on lookup, stat on create, stat on open, etc. I'll probably play around with it, since POSIX is an API specification, it's perfectly reasonable to implement it in the library (yet another loophole, again probably for VMS). > >Directories, on the other hand, do not even need to be considered as files > >at all... the update semantics are based on the opendir/readdir. The > > They do for creat() etc. Well, yes, for creat(), but not for traversal. I'd argue in favor of exempting stat, as well, although that would hardly result in a useful implementation. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9501031723.AA04465>