Realpath & context sensitive symlinks
James Antill
james@and.org
Fri Sep 28 16:20:00 GMT 2001
Andreas Schwab <schwab@suse.de> writes:
> Daniel Jacobowitz <drow@mvista.com> writes:
>
> |> On Thu, Sep 27, 2001 at 05:07:20PM -0400, James Antill wrote:
> |> > Michael Eager <eager@mvista.com> writes:
> |> >
> |> > > This macro
> |> > > substitution only occurs when the file system is following a symlink,
> |> > > otherwise the macro is left unmodified.
> |> >
> |> > Why? Is it done just so you can display it "raw" in ls. I can't think
> |> > of any other use for the "raw" value and a bunch of things probably
> |> > rely on stuff being valid from readlink() (just hope nothing changes
> |> > uid etc. before it uses them).
> |>
> |> We've (often and vocally) wondered the same thing :) It's completely
> |> POSIX conformant, regrettably; at least as far as I can tell. The
> |> value returned from readlink () is not required to be "useful" in any
> |> real sense.
>
> And hasn't been already for a long time on Linux as well, just look at the
> symlinks in /proc/$PID/fd if the file is a pipe or socket, or points to a
> deleted file.
While I sort of agree, and thought of that before my first response
there are two big differences:
1. The info. in /proc is not "raw", Ie. It is already resolved as much
as possible and the fact it doesn't point to a real file is because
it'll never point to a real file. In contrast the symlink hacks (there
have been a few) aren't information, they are symlinks to normal files
(and so things could expect them to act like them ... Ie. readlink()
returning where it actually points to).
2. No real programs care about /proc because the only programs that
play there know what they are doing (Ie. powertweak or a sys admin
with a shell), people don't save files there etc.
--
# James Antill -- james@and.org
:0:
* ^From: .*james@and\.org
/dev/null
More information about the Libc-alpha
mailing list