#10 Implementation for directory_symlinks option

[Andrey Zabolotnyi]

This small patch will add a new option "directory_symlinks" that will show any symbolic link as regular directories. This is pretty helpful in the following case:

Suppose you log in to some server and you're not chrooted, so:

curlftpfs ftp://some.server /mnt/server -o user=joe

Then "ls -la /mnt/server" will show the contents of /home/joe directory, and you don't have a way to see any files up in the hierarchy.

Now suppose you have a symbolic link in your home directory on the server: ftp -> /var/ftp

Without this patch /var/ftp will refer to your own /var/ftp, and that's now what we want. This could be fixed with the 'transform_symlinks' option but you don't have access to server's /var/ftp through curlftpfs, as explained above.

On the other hand, if we treat symlinks as directories, this will work perfectly. If you access, say, ftp/pub/somefile.txt this will work because on server this will get translated to /var/ftp/pub/somefile.txt which is correct.

There's a drawback when using this option though: this approach works only for directory symlinks. Symlinked files also appear as directories as there's no simple way to differentiate between a link to a directory and a link to a file :-( so you can't read symlinked files. But this is a minor drawback compared to the headache I had before I made this patch (I have lots of directory symlinks to different parts of the server's filesystem in my home directory).

[Andrey Zabolotnyi]

The diff against the 0.9.1 release

[Eric Price]

Logged In: YES
user_id=510612
Originator: NO

I think this is not what one would expect from a filesystem. if I copy a directory to a different position, and it has a symlink to /tmp it is always treated as a symlink to /tmp on the client machine. Thats how symlinks are supposed to work under *ix

Then again, when accessing a ftp server via an ftp client program, one is semi-logged in to the server and as such symlinks get handled server-specific, but thats a speciality of ftp, and it would imho be a bad idea to treat symlinks in mounted ftp shares differently than symlinks in any other (local or nfs) mounted volume.

Then again this might hide otherwise accessible resources on the server from a curlftpfs client.

Which means to have both, the client would need to have separate treatment to client relative and server relative symlinks. The question is how to represent that to the user.

If
ln -s /tmp cachedir
creates a symlink to client sieded /tmp - which is what you would expect from the command,
how can you issue the creation of a server side link?
a user defined system call utilized by an 'ftpln' command shipped with curlftpfs?
simulate the behaviour somehow with a hard link as in
ln /tmp cachedir ?

there needs to be more thought put into this, than just fixing one shortcoming with the creation of another