Ticket #1828: Improved symlink handling in ftpfs

Ticket #1828: Improved symlink handling in ftpfs

Originally from: http://mail.gnome.org/archives/mc-devel/2005-April/msg00035.html

The routines `vfs_s_find_entry_linear()' and `vfs_s_find_entry_tree()'
call `canonicalize_pathname()' on entry. This routine eats `..' path
components in certain cases. In case of ftpfs this is not desired -
the path should be kept as is since the code in direntry.c doesn't have
enough knowledge of the directory structure on the remote end.

Assume that
there is a path like this on the remote server

    /path1/path2/path3

The `path2' component is a symlink to some directory and `path3' is a
symlink stored in `path2' which is relative to `path2' i.e.

path2

    path3 -> ../some/other/path

Now, the code in direntry.c will determine that `path3' is a symlink and
will try to resolve (vfs_s_resolve_symlink) it by passing the following path

    /path1/path2/../some/other/path

to `vfs_s_find_entry_linear' . As I've said above this routine calls
`canonicalize_pathname' on entry which will modify the path like this:

    /path1/some/other/path

Now this is clearly wrong since `path2' is a symlink and it should be
resolved first. In the case of ftpfs the code in direntry.c doesn't have
enough knowledge about physycal directory layout on the remote filesystem
so it shouldn't try to canonicalize the path. The path should be left as
is and passed to the remote end for processing.

Fix issue:
Changed function canonicalize_pathname (as fact, renamed to custom_canonicalize_pathname)
In this function added ability to partial canonicalize of pathname.
And some functions from vfs/direntry.c calls custom_canonicalize_pathname without
removal of '..' stuff.

Signed-off-by: Slava Zanko <slavazanko@gmail.com>