Re: CVS commit: basesrc/usr.bin/ftp

[woods%weird.com@localhost (Greg A. Woods)]

[ On Friday, July 5, 2002 at 06:58:18 (+1000), Luke Mewburn wrote: ]
> Subject: Re: CVS commit: basesrc/usr.bin/ftp
>
> 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/15419q]
>   | 
>   | "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.

Well, your wording in the change is still incomplete and very
misleading.

"read access" is _not_ always required -- only whatever access is
necessary for "cd" to work (which is of course just "search access" on
unix-like systems with a proper ftp).  That may be "read access" for
some non-unix system or perhaps even for some arguably broken ftpd on a
unix-like system, but saying generically that "read access" is required
is wrong and would be very misleading for anyone attempting to get
things right for a proper ftpd on a unix-like system.

Did you ever receive the output you requested from the submitter?  Was
there any indication of what the server platform was?  I can't
understand the notation used in the PR.  If it's supposed to be "chmod"
command-line flags then that would hint a unix-like system, and if so
then that strongly suggests the server ftpd was at fault.  On the other
hand perhaps the notation is supposed to be something like what 'ls -l'
shows, but for some non-unix system, in which case it makes no sense to
me.

You also didn't document the example work-arounds given in the PR, and
indeed if this is a common problem with some well known ftpd then both
the examples given in the PR would be very worthwhile.

-- 
                                                                Greg A. Woods

+1 416 218-0098;            <g.a.woods%ieee.org@localhost>;           
<woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost>; VE3TCP; Secrets of the Weird 
<woods%weird.com@localhost>