[PATCH] Adds support for SSH_FXP_LINK request to sftp-server and sftp client

[Peter Collingbourne]

On Tue, May 08, 2007 at 05:13:39PM +0200, Daniele Calore wrote:
> Hi,
> 
> > Attached is a patch that adds support for the SSH_FXP_LINK request, as
> > described in draft-ietf-secsh-filexfer-07 onwards, to the sftp server
> > and client.
> 
> The "standard" for OpenSSH is draft-ietf-secsh-filexfer-03
> 
> $ grep FILEXFER_VERSION sftp.h
> #define SSH2_FILEXFER_VERSION           3
> 
> I have tried the patch and it works.
> But only if the client/server has the same patch installed.
> 
> There is a check inside the patch (sftp-client.c):
> 
> + if (conn->version < 3) {
> +     error("This server does not support the link operation");
> +     return(SSH2_FX_OP_UNSUPPORTED);
> + }
> 
> A non patched server has version "3" (see sftp.h) but
> it does not support the new link operation...
> 
> - Solutions:
> 1- Upgrade define SSH2_FILEXFER_VERSION to 4 ???
>    (and also update the check)

If we do this then perhaps it should go to 7 (I assume the version
numbers correspond to drafts?)  But then we may not be completely
compliant with 7 yet.  Of course if the check fails we should revert
to sending a SYMLINK request (if version >= 3), but only if sym =
1. This is because only the hardlink request requires the oldpath to
be normalised, and sending a normalised oldpath for a symlink request
would lead to problems.

This behaviour would cause compatibility problems if the bare 'ln'
command is issued to a new client connected to an old server, not
to mention the fact that the behaviour of ln has changed anyway.
Perhaps the best course of action would be to change the -s flag to
an -h flag, with the default being softlinks?  Of course this would
be inconsistent with the ln(1) command.

An alternate course of action would be to check the version number
in the user interface code and issue the appropriate request, but
this I feel breaks separation of concerns.

Thanks,
-- 
Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070508/60f3d721/attachment.bin