Date: Tue, 16 Nov 1999 09:47:05 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Laurynas Biveinis cc: djgpp-workers AT delorie DOT com Subject: Re: First alpha symlink patch In-Reply-To: <38305AFA.F17C62CA@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, 15 Nov 1999, Laurynas Biveinis wrote: > OK, tried it with chdir(), tried with my own chdir() through __dpmi_int() - > everything works. Of course, if I use __dpmi_int(), I have to resolve > symlinks by hand, and getwd() returns real directory instead. __dpmi_int is a simulation of any possible way of changing current directory behind our back, for example, if you run some child program which chdirs. I don't know if there's a problem with the behavior you see. But it strikes me that if we don't support returning a symlink from getcwd, then we don't need to record it and don't need to be bothered about such cases. > > DOS can do it because it is itself the server of the chdir call. Our > > libc isn't, so it isn't simple for it to keep track of cwd. > > Yes, but I try to determine, when I can and when I cannot keep track of > current dir: in chdir() I remember real directory name as well as symlink, > and in getwd() I always make a DOS call and compare results with real > directory name. Only if they match, I return symlink. IMHO this way > should work. It probably will work. I was just questioning the purpose of going to all that length, only to support a feature that even some Unix flavors don't care to support.