Message-ID: <37CA34BD.49B37284@softhome.net> Date: Mon, 30 Aug 1999 09:37:33 +0200 From: Laurynas Biveinis X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: lt,en MIME-Version: 1.0 To: Eli Zaretskii CC: DJGPP Workers Subject: Re: symlink() & is_v2_prog() question References: Content-Type: text/plain; charset=iso-8859-4 Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Eli Zaretskii wrote: [snip] Thanks for clarifying this out. > Of course, if `symlink' is going to support any type of file, then > this should be reconsidered and maybe changed. The decision depends, > among other factors, on whether the symlink for a DJGPP executable > will still be created like it is done today (i.e., by stubediting an > empty stub), or perhaps it will use the general mechanism like the > other files. Yes, I've thought about it. I want to leave current .exe symlinks in addition to new ones, because they work well from plain DOS. On the other hand, they're not detected by stat(), readlink() as symlinks. I think I'll enable current way in case when link source is valid v2 executable and use new way for everything else. What I've written so far: - new fully working symlink() (issues above will be resolved soon) - 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. - 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. 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. Laurynas Biveinis