Re: [ftpext] A few comments on draft-bryan-ftp-hash-05

Tim Kosse <tim.kosse@filezilla-project.org> Tue, 13 July 2010 22:40 UTC

Return-Path: <tim.kosse@filezilla-project.org>
X-Original-To: ftpext@core3.amsl.com
Delivered-To: ftpext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FDE83A6A0D for <ftpext@core3.amsl.com>; Tue, 13 Jul 2010 15:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00laiNHkTvhw for <ftpext@core3.amsl.com>; Tue, 13 Jul 2010 15:40:41 -0700 (PDT)
Received: from filezilla-project.org (cl-1464.dus-01.de.sixxs.net [IPv6:2a01:198:200:5b7::2]) by core3.amsl.com (Postfix) with ESMTP id 652EE3A6833 for <ftpext@ietf.org>; Tue, 13 Jul 2010 15:40:41 -0700 (PDT)
Received: from p4fe0c62b.dip.t-dialin.net ([79.224.198.43] helo=[192.168.0.203]) by filezilla-project.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <tim.kosse@filezilla-project.org>) id 1OYo9e-0002zc-Md; Wed, 14 Jul 2010 00:40:47 +0200
Message-ID: <4C3CEB60.1040903@filezilla-project.org>
Date: Wed, 14 Jul 2010 00:40:32 +0200
From: Tim Kosse <tim.kosse@filezilla-project.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: Robert McMurray <robmcm@microsoft.com>
References: <OF5B8F7FAC.BDF21341-ON80257752.00272796-80257752.002FC71F@uk.ibm.com> <4C2F1B7A.2040707@filezilla-project.org> <AANLkTinkcSl8PaGIQpJtGPfgGds5MvjXyxZYo1bJVDrJ@mail.gmail.com> <A5FC996C3C37DC4DA5076F1046B5674C3685A295@TK5EX14MBXC129.redmond.corp.microsoft.com>
In-Reply-To: <A5FC996C3C37DC4DA5076F1046B5674C3685A295@TK5EX14MBXC129.redmond.corp.microsoft.com>
X-Enigmail-Version: 1.1.1
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigF204E08A7DBBEFFC8BAD0C0C"
Cc: "ftpext@ietf.org" <ftpext@ietf.org>
Subject: Re: [ftpext] A few comments on draft-bryan-ftp-hash-05
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jul 2010 22:40:42 -0000

Hi,

On 2010-07-14 00:01, Robert McMurray wrote:
> why not return a list of filenames with their associated hashes for the directory [...]? For example:
> 
> C> HASH /foo/
> S> 125 Data connection already open; transfer starting.
> S> MD5 F0E1D2C3B4A5968778695A4B3C2D1E0F file1.txt
> S> MD5 78695A4B3C2D1E0FF0E1D2C3B4A59687 file2.txt
> S> MD5 0F1E2D3C4B5A69788796A5B4C3D2E1F0 file3.txt
> S> 226 Transfer complete.

Are you proposing to use a data connection just like with RETR/STOR and
the likes? If so, how to distinguish between getting the hash for a
single file (as sent over the control connection) and getting the hashes
for an entire directory?

Either all data needs to be sent over the transfer connection or the
transfer connection must never be used for HASH, otherwise the client
would not know when to send PORT/PASV... in preparation.

In case everything goes over the transfer connection, I see a problem
with directories containing only a single file with a name identical to
that of the directory:
> S> MD5 F0E1D2C3B4A5968778695A4B3C2D1E0F file1.txt

Is it a file named file1.txt in the current directory or a file named
file1.txt in the file1.txt directory? This this getting even more
complicated considering that the FTP specs do not mandate a particular
path syntax.

The other possible solution would be to use a multi-line response.


Last but not least, what should happen if the client issues HASH on a
directory containing over a million files?



Tim