Mail Archives: djgpp-workers/1999/08/30/06:53:05
On Mon, 30 Aug 1999, Laurynas Biveinis wrote:
> - new library function readlink() and its docs, taken from glibc-2.1.1.
> In fact, glibc-2.1.1 manual is my single source of info about symlinks.
Beware: glibc is under LGPL, so looking too hard inside it might get you
in legal trouble with your sources and the docs.
> - new library function lstat() and its docs ("stat() not following
> symlinks"), which is, in reality, renamed stat().
> - adapted stat() to follow symlinks (throwing EMLINK when neccesarry).
> - new macros in <sys/stat.h> S_ISLNK and S_IFLNK.
> - updated _PC_LINK_MAX and _POSIX_LINK_MAX. I haven't decided what value
> put there, because it is limited by stack size and nothing else.
> - new (taken from glibc) open() flag O_NOLINK, still unimplemented.
I assume you want this to get into libc.a some day. If so, I would like
once again to suggest that we discuss the various implications of this
feature before you invest too much effort (unless you don't mind wasting
it; most people do). I'm still wondering what benefits symlinks will
bring that justify such a thorough rewrite of core library functions.
For example, what would we lose if we simply augment `symlink' with code
that calls `link' if the target is not a DJGPP executable? The effect is
the same (albeit with some disk space wasted), but it's much less hassle
to implement and it doesn't rock the boat so much.
> Now I am making lstat() to recognize symlinks and set mode bits, then
> I'll update open(). That will be enough for symlinks to files.
What about `remove' and `rename'? Don't they have any effect on
symlinks.
- Raw text -