Date:	Tue, 16 Nov 1999 09:47:05 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Laurynas Biveinis <lauras AT softhome DOT net>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: First alpha symlink patch
In-Reply-To:	<38305AFA.F17C62CA@softhome.net>
Message-ID:	<Pine.SUN.3.91.991116094655.6671O-100000@is>
MIME-Version:	1.0
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

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.

- Raw text -