Date: Mon, 30 Aug 1999 12:11:49 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Laurynas Biveinis cc: DJGPP Workers Subject: Re: symlink() & is_v2_prog() question In-Reply-To: <37CA34BD.49B37284@softhome.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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 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.