Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E010449.4673F8E9@phekda.freeserve.co.uk>
Date: Wed, 18 Dec 2002 23:27:05 +0000
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: DJGPP workers <djgpp-workers AT delorie DOT com>
Subject: Problems with __solve_symlinks
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

There seem to be some problems with the __solve_symlinks function. Consider a
symlink like this:

    c:/tmp/part-symlink/rem_sl -> a:/loc_reg

(These are named to be like a failing fileutils test case, if you're
wondering.)

__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.

This has unfortunate consequences. stat, for instance, will not return the
same information for c:/tmp/<blah> and c://tmp/<blah>, because it thinks they
are different files. For the single-slash case, it will return information for
the file a:/loc_reg, which has been derefenced correctly. In the double-slash
case, it will return information for the file c:/tmp/part-symlink/rem_sl,
because it has no dereferenced the symlink correctly.

Because stat is broken, weird things happen in the fileutils test suite, where
it uses double-slashes a lot. (I specify a:/ as a temporary directory rather
than a:, so all the test paths end up as a://<something>.)

I've implemented a fix that eliminates double-slashes, except at the start for
UNCs (e.g.: \\mycomputer\someshare\somefile). Unfortunately this isn't enough.
__solve_symlinks also fails for relative paths such as
c:../../../../tmp/part-symlink/rem_sl.

So it seems that we need to:

* collapse slashes;
* get the current working directory, so that relative paths work.

before resolving the symlink. 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?

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]