SourceForge.net | 1 Apr 09:38 2003
Picon
Picon

[ curl-Bugs-713174 ] libcurl fails to perform more operations with same handle

Bugs item #713174, was opened at 2003-03-31 23:38
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=713174&group_id=976

Category: ftp
Group: bad behaviour
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Daniel Stenberg (bagder)
Summary: libcurl fails to perform more operations with same handle

Initial Comment:
LibCURL version 7.10.3 fails to perform more 
easy_perform()s with the same handle. Calling easy_init
() for each easy_perform() solves this problem.
The actual problem appeared when I tried to upload file 
after download. The uploaded file has size 0 although 
LibCURL says everything is ok. Tested with multiple ftp 
servers and files, always the same behaviour (LibCURL 
compiled for Win32).
(Maybe this problem is already solved in 7.10.4. 
prerelease, I just wanted to let you know...)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=713174&group_id=976

(Continue reading)

Daniel Stenberg | 2 Apr 10:03 2003
Picon

ANNOUNCE: curl and libcurl 7.10.4

Curl and libcurl 7.10.4 is out! A bugfix release.

Download from http://curl.haxx.se/download.html. As usual, allow some time
before the popular binary archives are up-to-date with this release.

Get curl from your favorite mirror by using this service:
http://curl.haxx.se/latest.cgi

Make sure the files haven't been tampered with by the time they land in your
filesystem by using these MD5 sums:

f7bf1651e5825744ab405490295fe98a  curl-7.10.4.tar.gz
6ea69876573104384be9d7f4c346ae33  curl-7.10.4.tar.bz2
cbaa9e9077dcd937b5faacd1f7ddcbf9  curl-7.10.4.zip

This release includes the following changes:

 o curl tool "clears" sensitive commands line args from ps output
 o no emacs local variables in the source files anymore, curl-style.el is the
   new file to use.
 o added script for distributed, automatic, multi-platform testing. Please
   join up and help us test the bleeding edge curl on various platforms!
 o the "scratch buffer" only allocated when actually needed. This drasticly
   reduces the amount of memory used for a single handle.
 o started implementing the 'share' system (detailed elsewhere)
 o removed the strequal and strnequal macros from curl/curl.h
 o added CURLOPT_UNRESTRICTED_AUTH / --location-trusted

This release includes the following bugfixes:

(Continue reading)

Roth, Kevin P. | 2 Apr 19:42 2003

FTP server issue in 7.10.4

I was looking forward to building up this new version, but ran into a long list of tests that failed:

 102 103 106 120 121 124 126 127 136 137

They were getting "curl returned status 18, when 0 was expected". And the stderr files told more - they said
something like "51 bytes expected, but received 57".

After some digging, the problem appears to be related to line-endings again. I made the following patch to
tests/ftpserver.pl, and they seemed to be fine after that:

---------------------------
 <at>  <at>  -192,6 +192,7  <at>  <at> 
         $size=0;
          <at> data = getpart("reply", "data");
         for( <at> data) {
+            s/\n/\r\n/; #must change \n's to \r\n's
             $size += length($_);
         }
         if($size) {
---------------------------

Apparently, the data being read in from the test102 file had unix line-endings (\n), but when printing the
data back out to the SOCK in ftpserver.pl, those were getting changed to \r\n's (internet standard...).
Changing the size calculation to be aware of this switch fixes the issue.

I don't know whether this affects just windows machines, or all of them...

I also had to adjust test #110. It had a hard-coded size of 85, and after changing it to 87 it worked OK.

There may be a more elegant solution; I'll leave it up to Daniel to choose how best to fix this.
(Continue reading)

Roth, Kevin P. | 2 Apr 23:22 2003

RE: FTP server issue in 7.10.4

One minor update - the box on which this was needed was running perl 5.8.0, built for cygwin. On my "older"
build machine, running perl 5.6.1, this change is NOT necessary.

I seem to recall there are some I/O changes in 5.8.0, that would recognize it's running on windows and choose
windows-ish line endings when `print`ing. There's an option to change IO modes back to the pre-5.8
behavior, but I'm not sure what that option is...

- Kevin

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Daniel Stenberg | 2 Apr 23:40 2003
Picon

Re: FTP server issue in 7.10.4

On Wed, 2 Apr 2003, Roth, Kevin P. wrote:

> I was looking forward to building up this new version, but ran into a long
> list of tests that failed:
>
>  102 103 106 120 121 124 126 127 136 137

Annoying.

> After some digging, the problem appears to be related to line-endings
> again. I made the following patch to tests/ftpserver.pl, and they seemed to
> be fine after that:

[CR to CRLF conversion patch cut out]

> Apparently, the data being read in from the test102 file had unix
> line-endings (\n), but when printing the data back out to the SOCK in
> ftpserver.pl, those were getting changed to \r\n's (internet standard...).
> Changing the size calculation to be aware of this switch fixes the issue.

I would prefer to work harder on getting all the data read, written, received
and sent as binary.

Can you check if inserting 'binmode SOCK;' after the socket(SOCK, ...) and
accept(SOCK, ...) calls makes it work better?

> I don't know whether this affects just windows machines, or all of them...

Most non-windows operating systems don't use text vs binary modes, and thus
won't be affected.
(Continue reading)

SourceForge.net | 3 Apr 09:39 2003
Picon
Picon

[ curl-Bugs-714443 ] File man3/curl_strnequal.3 wrong

Bugs item #714443, was opened at 2003-04-03 09:39
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=714443&group_id=976

Category: documentation
Group: wrong content
Status: Open
Resolution: None
Priority: 5
Submitted By: Matteo Beccati (ciaccia)
Assigned to: Daniel Stenberg (bagder)
Summary: File man3/curl_strnequal.3 wrong

Initial Comment:
Hi,

on my system (Debian GNU/Linux 3.0 + testing), 
compiling and installing curl 7.10.3 and 7.10.4 would 
give errors when mandb is run.

curl_strnequal.3 file has this content:
.so curl_strequal.3

while:
.so man3/curl_strequal.3

doesn't give the same error... is it my fault?

This is curl -V output:
curl 7.10.4 (i686-pc-linux-gnu) libcurl/7.10.4 
(Continue reading)

Daniel Stenberg | 3 Apr 13:29 2003
Picon

Re: FTP server issue in 7.10.4

On Wed, 2 Apr 2003, Roth, Kevin P. wrote:

> p.s. Tests 500 and 503 are still not working, if run after a previous one
> (such as 138). They work fine individually though. Daniel - I think you
> said you grabbed a copy of Cygwin and fixed this problem; did the fix make
> it into this codebase?

I must have been halucinating badly. I've now tried them myself on a cygwin
installation and I get the same failures on test 500 and 503 as you.

Let me get my shovel and I'll go start digging.

--

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

Daniel Stenberg | 3 Apr 15:47 2003
Picon

Re: FTP server issue in 7.10.4

On Wed, 2 Apr 2003, Roth, Kevin P. wrote:

> p.s. Tests 500 and 503 are still not working, if run after a previous one
> (such as 138). They work fine individually though. Daniel - I think you
> said you grabbed a copy of Cygwin and fixed this problem; did the fix make
> it into this codebase?

Ok, I made the tests run fine on my cygwin installation by applying the patch
that is now available here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/curl/curl/tests/ftpserver.pl.diff?r1=1.32&r2=1.33

It turned out cygwin isn't unix after all! ;-)

--

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

SourceForge.net | 3 Apr 17:17 2003
Picon
Picon

[ curl-Bugs-714667 ] curl -z ./local.bz2 -O ftp://remote.bz2 does not work

Bugs item #714667, was opened at 2003-04-03 07:17
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=714667&group_id=976

Category: client module
Group: wrong behaviour
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Daniel Stenberg (bagder)
Summary: curl -z ./local.bz2 -O ftp://remote.bz2 does not work

Initial Comment:
Hi,

if I got e.g.a  new mozilla.bz2 and than I perform:

curl -z ./mozilla-source.tar.bz2 -O
ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-source.tar.bz2

mozilla-source.tar.bz2 will be transferred a second
time. I observed this behaviour with:
curl 7.10.4 (i686-pc-linux-gnu) libcurl/7.10.4
OpenSSL/0.9.7 ipv6 zlib/1.1.4
and with
curl 7.10.2 (i686-pc-linux-gnu) libcurl/7.10.4
OpenSSL/0.9.6 ipv6 zlib/1.1.4

I supposed that it should not transferred twice. It is
(Continue reading)

Daniel Stenberg | 3 Apr 17:20 2003
Picon

Re: [ curl-Bugs-714667 ] curl -z ./local.bz2 -O ftp://remote.bz2 does not work

On Thu, 3 Apr 2003, SourceForge.net wrote:

[ I'm replying to this report by mail, see the full report at this URL:
http://sourceforge.net/tracker/index.php?func=detail&aid=714667&group_id=976&atid=100976
]

> if I got e.g.a  new mozilla.bz2 and than I perform:
>
> curl -z ./mozilla-source.tar.bz2 -O
> ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-source.tar.bz2
>
> mozilla-source.tar.bz2 will be transferred a second
> time. I observed this behaviour with:
> curl 7.10.4 (i686-pc-linux-gnu) libcurl/7.10.4
> OpenSSL/0.9.7 ipv6 zlib/1.1.4
> and with
> curl 7.10.2 (i686-pc-linux-gnu) libcurl/7.10.4
> OpenSSL/0.9.6 ipv6 zlib/1.1.4
>
> I supposed that it should not transferred twice. It is observed on a
> linux-2.4.20 system.

Well, it all boils down to what the FTP sever supports and responds. Can you
run a --trace-ascii and tell us exactly what kind of interaction curl does
with the FTP server in the second command invoke?

The MDTM command used for getting a time and date of a specific file over FTP
is 1. not a standard RFC959 command and 2. not very cleverly added since it
lacks time zone info.

(Continue reading)


Gmane