Hi,
I got a weird problem with curlftpfs 0.9.2 (in svn) and libcurl 7.18.
(It worked with libcurl 7.17.0).
When i try to download a file with cat /filename (this operation uses
curl_multi_perform()), the first attempt fails. Libcurl seems to try to
reconnect and sends garbage as user and password (see below). All the
other operations (which use curl_easy) and later download attempts work.
Is there any know bug or behavioral change in libcurl, which might be
related to this?
The current curlftpfs code is here:
http://code.google.com/p/curlftpfs/source/checkout
Cheers,
Norbert
* STATE: INIT => CONNECT handle 0x80906cc; (connection #-5000)
* Couldn't find host www.xxxxxx.at in the .netrc file, using defaults
* About to connect() to www.xxxxxxx.at port 8021 (#0)
* Trying 192.168.5.2... * STATE: CONNECT => WAITCONNECT handle
0x80906cc; (connection #0)
* Connected to www.xxxxxxxx.at (192.168.5.2) port 8021 (#0)
* FTP 0x8067978 state change from STOP to WAIT220
* STATE: WAITCONNECT => PROTOCONNECT handle 0x80906cc; (connection #0)
< 220 ready();
> USER 168.5.2
* FTP 0x8067978 state change from WAIT220 to USER
< 331 Password required for 168.5.2.
> PASS xxxxxxxxxxxx
* FTP 0x8067978 state change from USER to PASS
< 530 Login incorrect.
* Access denied: 530
* Expire cleared
* Closing connection #0
* STATE: PROTOCONNECT => COMPLETED handle 0x80906cc; (connection #-5000)
1209116192 ftpfs.c:392 error: curl_multi_info 1
Logged In: YES
user_id=236775
Originator: NO
Is this the same problem as discussed here: http://curl.haxx.se/mail/archive-2008-02/0018.html and http://curl.haxx.se/mail/lib-2008-02/0108.html ?
Logged In: YES
user_id=1110
Originator: NO
Can you provide us with a stand-alone example code that shows this problem? This could just as well be a curlftpfs problem for all we know...
Logged In: YES
user_id=704891
Originator: NO
Same problem here.
I put the stand-alone sample program here:
http://www.stevenshiau.org/misc/curlftpfs/
I used the curlftpfs codes from svn on code.google.com and complied it on Ubuntu 8.04. Some version info:
--------------------------
kernel 2.6.24-16-generic
curl 7.18.0-1ubuntu
libcurl3 7.18.0-1ubuntu
--------------------------
Thanks in advance.
Logged In: YES
user_id=1110
Originator: NO
Uhm, I can only see curlftpfs packages there? Which file is the stand-alone sample program?
And btw, calling libcurl 7.18.0 by SONAME *3* is a hack as libcurl is now on SONAME 4.
Logged In: YES
user_id=135573
Originator: YES
> Is this the same problem as discussed here:
> http://curl.haxx.se/mail/archive-2008-02/0018.html and
> http://curl.haxx.se/mail/lib-2008-02/0108.html ?
Yup, could be. Looks a bit like a pointer corruption problem. In both cases it sends weird characters (like parts of the IP-address or the URL) as user/password. It's probably hard to write a test-case for this, because it seems to only happen when reusing a curl_easy with multi_add.
Logged In: YES
user_id=1110
Originator: NO
Yes, but note that the other case of this reported problem ALSO involved curlftpfs and that nobody else have reported this problem so the pointer/memory problem could very well be in the curlftpfs code. If you cannot repeat this problem with a stand-alone program (without using curlftpfs) that'll remain my guess.
Logged In: YES
user_id=236775
Originator: NO
What is the complete sequence of operations to reproduce this using curlftpfs? What mount options? What is in the .netrc file? What operations on the filesystem?
Logged In: YES
user_id=135573
Originator: YES
co and compile: http://code.google.com/p/curlftpfs/source/checkout
curlftpfs -V
--> curlftpfs 0.9.2 libcurl/7.18.2-CVS fuse/2.7
run this in the first terminal:
mkdir /tmp/ftp
curlftpfs -v -o debug,ftpfs_debug=4,user=username www.host.org /tmp/ftp -f
in the second terminal:
cat /tmp/ftp/filename
i didn't use .netrc.
Logged In: YES
user_id=1110
Originator: NO
The attached libcurl patch seems to cure the problem for me!
Yeps, it certainly was a pointer mistake in libcurl. curlftpfs does a very unusual mix of the easy and multi interface which I think is the reason this is the only known victim of this problem.
Let me know how this patch works for you!
File Added: ftp-userpwd.patch
Logged In: YES
user_id=135573
Originator: YES
Thanks very much. This patch seems to fix the problem. And yes - curlftpfs is a bit like a hardcore testing suite for libcurl - i guess curl devels should keep an eye on it :-)
Norbert
Logged In: YES
user_id=1110
Originator: NO
Thanks for verifying, closing this report now.
And rather than "keep an eye" on curlftpfs we should strive to add test cases that make sure that even these kinds of uses are tested... IMHO of course.