Subject: Re: Symlink ownership (let's go back)
To: Steven J. Dovich <email@example.com>
From: nv90-mho <firstname.lastname@example.org>
Date: 08/11/1995 06:26:12
In message <199508081732.RAA32298@p400.sequoia.com>, "Steven J. Dovich" writes:
>I am not certain that such claims are made on the basis of direct
>inspection of the relevant draft. I will agree that posting the actual
>text is probably not worthwile, because it is a series of edit directives
>for changes to be made to the base standard. I will however summarize
>the specification, based on the last draft balloted (P1003.1a/D12).
>The definition of pathname resolution is modified to follow symlinks by
>default unless otherwise noted for an individual function. Path resolution
>in the presence of symlinks is specified in terms of string concatenation.
>The traditional functions for dealing with symlinks (symlink, readlink,
>and lstat) are specified. In struct stat, POSIX only specifies that
>"st_size" and "st_mode" have meaningful information for symlinks, and that
>the st_mode value is only meaningful as the argument to the S_ISLNK() macro.
>There are also changes to handle a few corner cases in functions like open(),
>These cases are largely things like opening a path naming a symlink
>(return with error if O_CREAT|O_EXCL).
Does that mean there is no escape from the "all-symlinks-have-same-time-
-rendering-ls -lt-virtually-useless-and-driving-me-nuts" syndrome?
Couldn't one at least hope for a tiny little st_mtime or something? :-)