Re: [PATCH] Improve sftp symlink support

[Christian Neumair <chris gnome-de org>]

Am Freitag, den 17.03.2006, 22:04 +0100 schrieb Christian Neumair:
> Am Donnerstag, den 16.03.2006, 20:20 +0100 schrieb Christian Neumair:
> > Am Donnerstag, den 16.03.2006, 11:06 +0100 schrieb Alexander Larsson:
> > > On Wed, 2006-03-15 at 14:16 +0100, Christian Neumair wrote:
> > > > The attached patch fixes most if not all issues with symlinks on sftp. A
> > > > known negative consequence is that it makes the module basically useless
> > > > for sftp servers with version "0".
> > > 
> > > How common are they,
> > 
> > I don't know. Wikipedia [1] claims that most clients use version 3 of
> > the protocol. I suppose that OpenSSH as a de-facto reference
> > implementation is authoritative, and it uses version 3 as well.
> > 
> > > and can we work around the problems by detecting this case?
> > 
> > Yes, we could in theory fall back to STAT for these like we did before,
> > although that woulds till render symlinks unusable (which would not be a
> > regression because we don't support them properly ATM anway).
> > 
> > If you take a look at the file-method semantics, which I used as a
> > pattern for the lstat/stat symlink resolution, you will see that the
> > file info can't be fetched reliably when only stat is available, and
> > this will render symlinks useless. The newest draft [2] seems to contain
> > some flags for treating invalid symlinks differently from valid ones,
> > however it still doesn't state clearly what to do with chained symlinks,
> > where GnomeVFS and Nautilus expect a very distinct behavior.
> > 
> > Unfortunately, I couldn't find all the SFTP drafts available to diff
> > them and see what precisely the version 0 stat command actually does.
> > 
> > Version 0 servers should at least be able to directory listings, since
> > the SFTP readdir will also provide some file info, i.e. do a stat.
> > 
> > [1] http://en.wikipedia.org/wiki/SSH_file_transfer_protocol
> > [2] http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-12.txt
> 
> [3] was written in 2003 and claims that "Most servers support both
> version 1 and 2, but more and more servers are discontinuing support for
> version 1.", so it doesn't even mention version 0. Ergo I think not
> supporting it is ok.
> 
> The attached patch now also handled NULL and "" paths better by
> canonicalizing them to "/", and it adds more DEBUG statements. Thanks to
> Priit Laes for pointing this glitch out.
> 
> [3] http://klomp.org/eclipse/org.klomp.eclipse.team.sftp/intro.html

Notably STAT_VERSION_0 maps to the same command identifier as LSTAT, and
even the *first* available IETF draft from 2001 [1] uses

#define SSH_FXP_VERSION             2

I couldn't find any paper describing how version 0 (let alone version 1)
looks.

If anybody uses a server of version 0, I will work together with him to
make this work, but I don't think it buys us much to handle this case
unless we know that it works and we know that the file info it returns
is usable at all. My personal guess is that version 0 didn't have
symlink support, and STAT_VERSION_0 just means LSTAT.

Do you want me to get in touch with the SFTP community to sort this out,
or should I just remove that special case from the patch, letting the
symlink resolution code run with SSH2_FXP_LSTAT/SSH2_FXP_STAT_VERSION_0.
There is quite a chance that it will work, and the file type will never
be set to GNOME_VFS_FILE_TYPE_SYMBOLIC_LINK for version 0 servers.

[1] http://lftp.yar.ru/draft-ietf-secsh-filexfer-00.txt

-- 
Christian Neumair <chris gnome-de org>