From owner-freebsd-current@FreeBSD.ORG Thu Mar 29 17:53:36 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09A4016A403 for ; Thu, 29 Mar 2007 17:53:36 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 915DB13C4D0 for ; Thu, 29 Mar 2007 17:53:35 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id E2E88690730; Thu, 29 Mar 2007 18:53:06 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id AF26F690812; Thu, 29 Mar 2007 18:53:06 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local (87-196-29-248.net.novis.pt [87.196.29.248]) by core.fnop.net (Postfix) with ESMTP id 33D3A690730; Thu, 29 Mar 2007 18:53:06 +0100 (WEST) Message-ID: <460BFD1D.9000402@fnop.net> Date: Thu, 29 Mar 2007 18:53:33 +0100 From: Rui Paulo User-Agent: Thunderbird 2.0b2 (Macintosh/20070116) MIME-Version: 1.0 To: Nate Lawson , =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <460AE39B.4070706@root.org> In-Reply-To: <460AE39B.4070706@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: current@FreeBSD.org Subject: Re: libfetch ftp patch for less latency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2007 17:53:36 -0000 Nate Lawson wrote: > To speed up pkg_add and other ftp command channel performance over slow > links, change this: > [...] > All ftp servers I've ever seen support a full path when changing down > dirs. This might be a DOS ftp server thing however. In any case, if > there is an error to the all-in-one CWD, the code reverts back to legacy > behavior of multiple CWDs. Yes, I think this behavior is acceptable. If the pathname fails it only adds one more CWD, but reduces the time on the successful cases (which are many if you consider the Ports collection). Dag-Erling Smørgrav wrote: > No. This is a violation of the FTP protocol. > [...] > When the all-in-one CWD fails, you're SOL. You have no idea what > state the server is in, and you have to start over. About the possible violation of the RFC, I quote: pathname Pathname is defined to be the character string which must be input to a file system by a user in order to identify a file. Pathname normally contains device and/or directory names, and ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ file name specification. FTP does not yet specify a standard ^^^^^^^^^^^^^^^^^^^^^^^ pathname convention. Each user must follow the file naming conventions of the file systems involved in the transfer. CHANGE WORKING DIRECTORY (CWD) This command allows the user to work with a different directory or dataset for file storage or retrieval without altering his login or accounting information. Transfer parameters are similarly unchanged. The argument is a pathname specifying a directory or other system dependent ^^^^^^^^ file group designator. I'm not sure why you consider this a violation of the protocol. Also, considering the reply codes to the CWD command, only 421 seems to change the server state. Have you seen servers that change their state by issuing giving invalid arguments to the CWD command ? Regards, -- Rui Paulo | PGP: F0E4 C7C7 1653 79B7 78DC DD73 64FA B2C6 CF45 1F84