Subject: Re: CVS commit: basesrc/usr.bin/ftp
To: Greg A. Woods <woods@weird.com>
From: Luke Mewburn <lukem@wasabisystems.com>
List: source-changes
Date: 07/05/2002 06:58:18
On Thu, Jul 04, 2002 at 12:40:10PM -0400, Greg A. Woods wrote:
  | > Log Message:
  | > highlight that for ftp:// auto-fetches, read access is required on
  | > intermediate directories because ftp(1) obeys RFC1738.  for [bin/15419]
  | 
  | "read access"
  | 
  | Is there some special meaning of that term in the FTP protocol that's
  | separate from the meaning implied by an FTP server running on a system
  | with unix-like filesystem semantics?
  | 
  | Filesystem read access on intermediate directories is _not_ required --
  | only search (i.e. 'x') access, at least not for any ftpd that just does
  | chdir(2) on any unix-like filesystem.

I am aware of UNIX's semantics.  But the submitter of pr 15419 has a
situation where the behaviour of ftp(1) parsing
ftp://somehost/private/foo/blah.tgz as
	connect to somehost
	cd private
	cd foo
	get blah.tgz
doesn't work due to permission issues.  (If ftp did "cd private/foo" instead
of "cd private ; cd foo", it does work).

I'm not sure which ftp server implementation caused the problem.
Since it was a problem, and it wasn't immediately apparent to the
PR submitter how ftp(1) was triggering the problem, I decided to
document how ftp(1) parses the ftp:// URLs which may have made it
more obvious to what was causing the problem.

Luke.