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

--===============1337888303==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="zBPbvmIlJjvpbu6L"
Content-Disposition: inline


--zBPbvmIlJjvpbu6L
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 08, 2007 at 05:13:39PM +0200, Daniele Calore wrote:
> Hi,
>=20
> > 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.
>=20
> The "standard" for OpenSSH is draft-ietf-secsh-filexfer-03
>=20
> $ grep FILEXFER_VERSION sftp.h
> #define SSH2_FILEXFER_VERSION 3
>=20
> I have tried the patch and it works.
> But only if the client/server has the same patch installed.
>=20
> There is a check inside the patch (sftp-client.c):
>=20
> + if (conn->version < 3) {
> + error("This server does not support the link operation");
> + return(SSH2_FX_OP_UNSUPPORTED);
> + }
>=20
> A non patched server has version "3" (see sftp.h) but
> it does not support the new link operation...
>=20
> - 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 >=3D 3), but only if sym =3D
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,
--=20
Peter

--zBPbvmIlJjvpbu6L
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGQK7CXDqn6DSH7HERAsiIAJ0UtICnLd/8VmpqCQu5o7Tx7ceZKgCfUnrX
JUCu39EtzWQzHIUKz+WHvTs=
=yMTp
-----END PGP SIGNATURE-----

--zBPbvmIlJjvpbu6L--

--===============1337888303==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
http://lists.mindrot.org/mailman/lis...enssh-unix-dev

--===============1337888303==--