Bugs item #1822405, was opened at 2007-10-29 23:27
Message generated for change (Comment added) made by norbertf
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1822405&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: hang
Status: Open
Resolution: Invalid
Priority: 5
Private: No
Submitted By: n.f. (norbertf)
Assigned to: Daniel Stenberg (bagder)
Summary: curlftpfs hangs after reading files with no write permission

Initial Comment:
i have already reported this problem to the curlftpfs bugzilla.

http://sourceforge.net/tracker/index.php?func=detail&aid=1809225&group_id=160565&atid=816357

i'm not sure if this is really a libcurl problem, but there is a suspicion that libcurl doesn't move into a working state after reading a file failed (because no read permissions for the ftp user).

if there is a possibility to reproduce this bug without curlftpfs please tell me and i will try (perhaps a peace of demo code, which also uses curl_multi).

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

>Comment By: n.f. (norbertf)
Date: 2007-10-30 21:25

Message:
Logged In: YES
user_id=135573
Originator: YES

no. i didn't test PORT mode, because curlftpfs doesn't seem to have a
switch to force PORT mode.

what i can say is that the problem occurs in EPSV but not in PASV mode.

i also found this "recommendation":

http://www.ohloh.net/projects/7238/contributors/40480/commits/11711342

and yes, the problem occurs on every hit (on my own ftp server - a
proftpd-1.2.9-1.9). actually i have to try to read two files with no read
permission and then reading the third (not read protected file) hangs.

i just tried on an external FTP server - also with EPSV - but i can't
reproduce the problem there.

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

Comment By: Dan Fandrich (dfandrich)
Date: 2007-10-30 21:00

Message:
Logged In: YES
user_id=236775
Originator: NO

Are you saying the problem occurs in PORT mode? Because the log attached
to the other bug is also using passive mode, as is test case 546 (EPSV
mode, to be specific). Does this problem happen every single time this
condition is hit, or just sporadically?

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

Comment By: n.f. (norbertf)
Date: 2007-10-30 20:32

Message:
Logged In: YES
user_id=135573
Originator: YES

i tried to investigate this further:

this behavior might indicate that this is a libcurl bug:
the problem goes away when i use PASV mode ( -o disable_epsv)

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

Comment By: Daniel Stenberg (bagder)
Date: 2007-10-30 10:06

Message:
Logged In: YES
user_id=1110
Originator: NO

Since this doesn't seem to be a bug in libcurl...

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

Comment By: n.f. (norbertf)
Date: 2007-10-30 01:18

Message:
Logged In: YES
user_id=135573
Originator: YES

thanks a lot, i will try your test-case as soon as possible.

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

Comment By: Dan Fandrich (dfandrich)
Date: 2007-10-30 00:51

Message:
Logged In: YES
user_id=236775
Originator: NO

The error code from the FTP server in both cases is 550, so from libcurl's
perspective it's identical. The difference with your case is that the SIZE
command succeeds, but libcurl handled that fine as well when I tried
changing the test case to match. It's possible that there are other
differences in how curlftpfs uses libcurl, but this test case at least
gives you a known-working baseline to which you can refer.

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

Comment By: n.f. (norbertf)
Date: 2007-10-30 00:33

Message:
Logged In: YES
user_id=135573
Originator: YES

thanks, but i think that's not a file-not-found problem, but a
permission-denied problem.

> RETR messages.4
* FTP 0x80658d0 state change from RETR_SIZE to RETR
< 550 messages.4: Permission denied
* RETR response: 550
...
> RETR messages.3
* FTP 0x80658d0 state change from RETR_SIZE to RETR
< 550 messages.3: Permission denied
* RETR response: 550
...

have a look at curlftplog.txt, which i attached to the curlftpfs bug
report.

after trying to read messages.4 and messages.3 (which both have no read
permissions), reading messages.2 (for which i have read permissions)
hangs:

...
> RETR messages.2
* FTP 0x80658d0 state change from RETR_SIZE to RETR
< 150 Opening BINARY mode data connection for messages.2 (84257 bytes)
* Maxdownload = -1
* Getting file with size: 84257
* FTP 0x80658d0 state change from RETR to STOP
* DO-MORE phase ends with 0
* STATE: DO_MORE => DO_DONE handle 0x808e3e4; (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x808e3e4; (connection #0)
* Conn 0 recv pipe 1 inuse 0 athead 1
* STATE: WAITPERFORM => PERFORM handle 0x808e3e4; (connection #0)

(hangs)

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

Comment By: Dan Fandrich (dfandrich)
Date: 2007-10-30 00:01

Message:
Logged In: YES
user_id=236775
Originator: NO

I've created test case 546 that tests a file-not-found FTP transfer
followed by a found one using the multi interface, and it passes fine.

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

Comment By: n.f. (norbertf)
Date: 2007-10-29 23:40

Message:
Logged In: YES
user_id=135573
Originator: YES

sorry - the title of this bug report should be:
curlftpfs hangs after reading files with no READ permission

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

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1822405&group_id=976
Received on 2007-10-30