1
1
Slava Zanko 4f36622725 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>
2009-12-25 15:53:48 +02:00
..
2009-12-16 11:10:42 +02:00
2009-12-16 11:10:43 +02:00
2009-08-13 00:32:26 +03:00
2009-12-16 11:10:43 +02:00
2009-12-23 22:31:30 +03:00
2009-05-27 14:53:23 +03:00
2003-06-02 19:47:30 +00:00
2009-12-16 11:10:42 +02:00

NOTE: Although vfs has been meant to be implemented as a separate
entity redistributable under the LGPL in its current implementation it
uses GPLed code from src/. So there are two possibilities if you want
to use vfs:

1. Distribute your copy of vfs under the GPL. Then you can freely
include the GPLed functions from the rest of the mc source code.

2. Distribute your copy of vfs under the LGPL. Then you cannot include
the functions outside the vfs subdirectory. You must then either
rewrite them or work around them in other ways.

========================================================================

Hi!

I'm midnight commander's vfs layer. Before you start hacking me,
please read this file. I'm integral part of midnight commander, but I
try to go out and live my life myself as a shared library, too. That
means that I should try to use as little functions from midnight as
possible (so I'm tiny, nice and people like me), that I should not
pollute name space by unnecessary symbols (so I do not crash fellow
programs) and that I should have a clean interface between myself and
midnight.

Because I'm rather close to midnight, try to:

* Keep the indentation as the rest of the code. Following could help
you with your friend emacs:

(defun mc-c-mode ()
	"C mode with adjusted defaults for use with the Midnight commander."
	(interactive)
	(c-mode)
	(c-set-style "K&R")
	(setq	c-indent-level 4
		c-continued-statement-offset 4
		c-brace-offset 0
		c-argdecl-indent 4
		c-label-offset -4
		c-brace-imaginary-offset 0
		c-continued-brace-offset 0
		c-tab-always-indent nil
		c-basic-offset 4
		tab-width 8
		comment-column 60))

(setq auto-mode-alist (cons '(".*/mc/.*\\.[ch]$" . mc-c-mode)
                       auto-mode-alist))

And because I'm trying to live life on my own as libvfs.so, try to:

* Make sure all exported symbols are defined in vfs.h and begin with
'vfs_'.

* Do not make any references from midnight into modules like tar. It
would probably pollute name space and midnight would depend on concrete
configuration of libvfs. mc_setctl() and mc_ctl() are your
friends. (And mine too :-).

							 Pavel Machek
							 pavel@ucw.cz

PS: If you'd like to use my features in whole operating system, you
might want to link me to rpc.nfsd. On
http://atrey.karlin.mff.cuni.cz/~pavel/podfuk/podfuk.html you'll find
how to do it.

PPS: I have a friend, shared library called avfs, which is LD_PRELOAD
capable. You can reach her at http://www.inf.bme.hu/~mszeredi/avfs.