cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Change in FTP output from 7.16.2 and 7.16.4.....

From: Robson Braga Araujo <robsonbraga_at_gmail.com>
Date: Fri, 17 Aug 2007 09:57:25 -0300

> > This change broke curlftpfs too. I don't see your point of "loads of
> > existing applications that use NOBODY today with the current meaning". Loads
> > of FTP applications used the NOBODY option with the previous meaning too and
> > you just broke them nonetheless. Why do you think that printing an
> > Accept-ranges: bytes is ok for an FTP connection?
>
> Okay, let's pick this apart.
>
> 1) I did this change on June 24th. Nobody objected at the time.
>
> 2) I didn't just change the behavior of ftp-NOBODY. I fixed a bug that was
> reported to us. The changed behavior on ftp-NOBODY was an unintended
> side-effect.
>
> 3) I did acknowledge that this changed behavior can cause trouble and I've
> tried to bring up a discussion on what we can do about it. Nobody (including
> you) has responded or commented on that. (And in general I drop subjects that
> nobody seems to care about when they (the subjects) don't bother me much.)
>
> 4) That printing of accept-ranges is not new, it's been in there for ages just
> as I explained and as you can see in the code/CVS for yourself. I actually
> guess it does more harm than good in there so we should probably cut it out...
>
> 5) Feel free to provide a fix. libcurl is a community project!

Don't feel offended! I was just arguing the technical merits of your
decision. So it turns out that this behavior is not really a problem
for curlftpfs. The fact that it does a "SIZE (null)" when you do a
NOBODY in a ftp directory is also strange but it is also harmless for
my application.

> > Also I get the following stack trace when using the NOBODY option in 7.16.4:
> >
> > #0 0xb7ee555c in Curl_client_write (conn=0x8065058,
> > type=<value optimized out>, ptr=0xb7f05c10 "Accept-ranges: bytes\r\n",
> > len=0) at sendf.c:180
> > #1 0xb7ee8497 in ftp_statemach_act (conn=0x8065058) at ftp.c:2126
> > #2 0xb7ee9428 in ftp_easy_statemach (conn=0x8065058) at ftp.c:2896
> > #3 0xb7ee9f95 in Curl_ftp (conn=0x8065058, done=0xb7b931fa) at ftp.c:3458
> > #4 0xb7eedf8a in Curl_do (connp=0xb7b931f4, done=0xb7b931fa) at url.c:4299
> > #5 0xb7efa595 in Curl_perform (data=0x805c798) at transfer.c:2421
> > #6 0xb7efafbe in curl_easy_perform (curl=0x805c798) at easy.c:492
> >
> > I suspect this is because you're passing a constant array there on
> > ftp.c:2126 and trying to change it on sendf.c:180.
>
> Indeed, convert_lineends()'s changing of the input buffer is bound to cause
> trouble for all those cases were a constant buffer is passed in... It is
> curious that we haven't seen this bug before! :-/

I have provided patches in the past as you can see in your logs but
this time I don't have time to do it. I'll open bugs in your bugtrack.

-- 
[]s,
Robson
   "You don't get to be mom if you can't fix everything just right." -Calvin
Received on 2007-08-17