Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E01B3BF.8EAE48F1@phekda.freeserve.co.uk>
Date: Thu, 19 Dec 2002 11:55:43 +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: Re: Problems with __solve_symlinks
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1021219081003 DOT 19808E-100000 AT is>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.
Eli Zaretskii wrote:
> 
> 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?

Yes, you are right. Pardon me - I was doing this stuff late last night.

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

More precisely: in a directory three levels deep from c:/,
c:../../../tmp/part-symlink/rem_sl resolves correctly.
c:../../../../tmp/part-symlink/rem_sl does not (it goes one level too far).
 
> > 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'm pretty sure it calls _fixpath in the right places. I'm fairly confident
there's a bug in libc.

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

I agree that using _fixpath seems wrong. It would also break the FSEXT support
in __internal_readlink - virtual paths would no longer be supported.

Ah, I think I see what's going on now. In the advance function in
src/libc/compat/unistd/xsymlink.c, the start pointer can get ahead of the end
pointer. Consider c://tmp/part-symlink/rem_sl:

start: c://tmp/part-symlink/rem_sl
end: //tmp/part-symlink/rem_sl
advance(start, end)
start: /tmp/part-symlink/rem_sl
end: /tmp/part-symlink/rem_sl
advance(start, end)
start: part-symlink/rem_sl
end: /part-symlink/rem_sl
advance(start, end)
start: rem_sl
end: /rem_sl

I'll try to come up with a fix for this and the too many '..' problem.

Bye, Rich =]

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