Mail Archives: djgpp-workers/2002/12/19/06:56:29
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/ ]
- Raw text -