Date:	Thu, 19 Dec 2002 08:14:52 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
cc:	DJGPP workers <djgpp-workers AT delorie DOT com>
Subject:	Re: Problems with __solve_symlinks
In-Reply-To:	<3E010449.4673F8E9@phekda.freeserve.co.uk>
Message-ID:	<Pine.SUN.3.91.1021219081003.19808E-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 18 Dec 2002, Richard Dawe wrote:

> __solve_symlinks on "c:/tmp/part-symlink/rem_sl" will return "a:/loc_reg".
> __solve_symlinks on "c://tmp/part-symlink/rem_sl" will return the same string.
> 
> __solve_symlinks calls findfirst to look for the existance of a symlink file.
> findfirst barfs on the double-slash and __solve_symlinks does not find the
> symlink file.

Sorry, I don't understand: `findfirst' calls `_put_path' to pass the file 
name to any DOS function via the transfer buffer, right?  And `_put_path' 
collapses multiple slashes, right?  So why isn't this being fixed before 
DOS sees the two slashes?  What am I missing?

> __solve_symlinks also fails for relative paths such as
> c:../../../../tmp/part-symlink/rem_sl.

Why is that?  Could you please analyze why these cases fail and post the 
description of what happens?

> Hmmm, this is starting to sound a bit like
> _fixpath. But it feels like _fixpath is too heavy for this purpose. However, I
> think we would want the other benefits of _fixpath - those from _put_path,
> like expanding environment variables. Thoughts?

The last port of Fileutils I worked on did indeed call _fixpath in 
several places, to solve similar problems.  Perhaps it should call 
_fixpath in a few more places now?

I don't think we should use _fixpath in low-level library functions, but 
perhaps I will change my mind when I understand the nature of the 
failures better.

- Raw text -