--===============0755226146==
Content-Type: multipart/alternative;
boundary="=====================_154868156==.ALT"

--=====================_154868156==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 01:49 AM 9/26/2007, Dariusz Pietrzak wrote:
> > 226 Transfer complete
> > ftp> quote size README.MIRRORS
> > ---> size README.MIRRORS
> > 550 SIZE not allowed in ASCII mode
> > Note that the client switches to ASCII mode to receive the output
> > from DIR, but does not reverse that.

> And that's good, otherwise you end up with windows-like behaviour like
> this:
> TYPE A
> LIST
> TYPE I
> TYPE A
> LIST
> TYPE I
> TYPE A
> LIST
> ...
>
> I see no need to reverse the mode until you're doing something that needs
>'TYPE I',


But, of course, that is really the point. The client _did_ reverse
the mode, which had been set by user request using a plain old BINARY
command. So it is really more surprising that it doesn't undo what
it just did, so as to put things back the way the user wanted them.

It is true that another sequence of commands to try would be
binary
dir
get foo
and see whether/that the client program does a "TYPE I" at that point.

>for example running SIZE, but, since you did that with QUOTE, the
>client had no way of knowing that you need the mode reversed.


And the user had no way of knowing the client was diddling the mode
behind the scenes ... :-)

>--
>Dariush Pietrzak,


--=====================_154868156==.ALT
Content-Type: text/html; charset="us-ascii"



At 01:49 AM 9/26/2007, Dariusz Pietrzak wrote:

>   226 Transfer
complete

>   ftp> quote size README.MIRRORS

>   ---> size README.MIRRORS

>   550 SIZE not allowed in ASCII mode

> Note that the client switches to ASCII mode to receive the output


> from DIR, but does not reverse that.

 And that's good, otherwise you end up with windows-like behaviour
like

 this:

 TYPE A

 LIST

 TYPE I

 TYPE A

 LIST

 TYPE I

 TYPE A

 LIST

 ...


 I see no need to reverse the mode until you're doing something that
needs

'TYPE I',


But, of course, that is really the point.  The client _did_ reverse
the mode, which had been set by user request using a plain old BINARY
command.  So it is really more surprising that it doesn't undo what
it just did, so as to put things back the way the user wanted them. 



It is true that another sequence of commands to try would be

    binary

    dir

    get foo

and see whether/that the client program does a "TYPE I" at that
point.


for example running
SIZE, but, since you did that with QUOTE, the

client had no way of knowing that you need the mode
reversed.


And the user had no way of knowing the client was diddling the mode
behind the scenes ... :-)


--

Dariush Pietrzak,



--=====================_154868156==.ALT--


--===============0755226146==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
--===============0755226146==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html
--===============0755226146==--