Date: Thu, 19 Dec 2002 08:14:52 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Richard Dawe cc: DJGPP workers Subject: Re: Problems with __solve_symlinks In-Reply-To: <3E010449.4673F8E9@phekda.freeserve.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.