From owner-freebsd-net@FreeBSD.ORG Tue Jun 28 18:14:53 2005 Return-Path: X-Original-To: freebsd-net@FreeBSD.org Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D67716A455; Tue, 28 Jun 2005 18:14:49 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1E7943D4C; Tue, 28 Jun 2005 18:14:48 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[65.202.103.25]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Tue, 28 Jun 2005 14:28:31 -0400 From: John Baldwin To: freebsd-net@FreeBSD.org User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Disposition: inline Date: Tue, 28 Jun 2005 13:38:13 -0400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200506281338.14511.jhb@FreeBSD.org> Cc: des@FreeBSD.org Subject: Bug in libfetch handling of FTP urls.. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2005 18:14:54 -0000 Ran into this at work. Suppose I am fetching a file over ftp for a user foo whose home dir is /home/foo' and I want to retrieve the 'bar/baz' file out of his home directory. According to my understanding of RFC 1378 (http://www.faqs.org/rfcs/rfc1738.html, specifically section 3.2.2), this URL should work: fetch ftp://foo@someserver/bar/baz However, we find that we have to specify the full path: fetch ftp://foo@someserver/home/foo/bar/baz It seems that fetch is including the '/' as part of the url-path and doing 'CWD /bar ; RETR baz' rather than treating it as a separator and doing 'CWD bar; RETR baz'. I verified this by doing 'fetch -vv' and seeing that it does one big CWD (instead of the multiple CWD's the RFC says should happen) and that it includes the leading '/' when it should not. Also, it seems that fetch ignores the ';type=X' optional part of the url-path and always uses TYPE I. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org