Message-ID: <3E48DD9D.8DB41DF7@yahoo.com>
Date: Tue, 11 Feb 2003 06:25:17 -0500
From: CBFalconer <cbfalconer AT yahoo DOT com>
Organization: Ched Research
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: Take on __solve_symlinks()
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1030211074233 DOT 25449A-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:
> On Mon, 10 Feb 2003, Richard Dawe wrote:
> 
> > It still doesn't work for the cases where ".."s go above the
> > root directory. So either findfirst (& findnext, I guess) or
> > __solve_symlinks needs to be fixed. But does the fix belong in
> > findfirst or __solve_symlinks?
> >
> > We could "fix" findfirst & findnext to cope with excess ".."s
> > on DOS.
> 
> IMHO, the fix should be in __solve_symlinks.  findfirst/findnext
> are more-or-less direct interfaces to DOS system calls, with no
> simple equivalent on Posix systems, and DOS barfs when there are
> excess ".." in the file name.  The feature whereby "/.." is
> equivalent to "/" is a Posix feature, so we should emulate that
> in the Posix layer.  Pure DOS functions such as findfirst should
> behave like DOS does.

IMO it depends on how DOS barfs.  If it returns an error, I agree
with you.  If it crashes, then I agree with Richard.  Speaking
from ignorance.

-- 
Chuck F (cbfalconer AT yahoo DOT com) (cbfalconer AT worldnet DOT att DOT net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!