ID: 20526 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: FTP related Operating System: MS Windows XP Pro PHP Version: 4.3.0RC1 New Comment:
OK. One last line from my side, then I will quit. I never intended to ask support questions here; I was (and in part I still am) of the opinion it was a real bug, otherwise I had spontaneously applied to other appropriate resources. It looks like your last comment in this page is actually a reply to my private e-mail. Regards. Previous Comments: ------------------------------------------------------------------------ [2002-12-06 09:53:53] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. FTP protocol uses 2 ports 1 for sending commands and the other for sending data. The connection that is being closed is the 'command' port since all the necessary commands have been already sent. The data port remains open until the file is sent/recieved at which point it is also closed. If the FTP server does not support this functionality I suspect it is the problem with the FTP server. Non of the FTP servers I've tried ncftpd, proftpd, wu-ftpd, BulletProof ftp and severals others have experienced this problem. ------------------------------------------------------------------------ [2002-11-27 16:18:15] [EMAIL PROTECTED] Tried php4-win32-STABLE-200211271730. Tried also php-4.3.0RC2-Win32. Unfortunately the behaviour of fopen with stp URL, in my opinion, is still not correct. Now the connection on the FTP data channel is established before issuing the QUIT command on the control channel (this was not so with previous versions); anyway the QUIT command is issued without waiting the end of the data transfer; depending on the time, the QUIT can reach the FTP server AFTER or BEFORE that the transfer is completed. Testing in loopback, most of the times the transfer is successful with the Bulletproof FTP server (http://www.bpftpserver.com/), but always fails with the GuildFTPd server (http://www.guildftpd.com/). In my opinion issuing of QUIT should be postponed until the end of the data transfer (or perhaps until fclose?). Many thanks for your attention. Giovanni. ------------------------------------------------------------------------ [2002-11-26 17:42:49] [EMAIL PROTECTED] Tried to comment-out lines 407 to 411 of file ftp_fopen_wrapper.c. With this temporary patch my little PHP program successfully reads the file via the wrapper!! Of course in no way this can be considered "a solution". In practice I have stripped off the QUIT. The question: should not the QUIT be sent only at fclose? ------------------------------------------------------------------------ [2002-11-26 05:56:57] [EMAIL PROTECTED] In the mean time I realized that the "FTP reports 227.." is not to be intended as "the error"; "the error" is "...failed to create stream..."; "FTP reports 227" is the result of a mere diagnostic aid. In addition I can see now that the problem is time-dependent; sometimes is "...failed to create stream...", sometimes the fopen returns a stream with no data (while there should be some!). Running a debug endowed rebuild of php-4.3.0RC1-Win32.zip and tracing the execution of ftp_fopen_wrapper.c I have seen that the "goto errexit" in line 419 is executed (datastream == NULL); it is strange to me that the datastream opening is attempted *after* that the QUIT command has been sent via the FTP control stream. Is that normal? I suspect that the FTP server gets the QUIT and kills or inhibits the data connection. I will try to momentarily comment-out the QUIT and see what happens. Anyway I will also look at and try the snapshot as you suggest. bye for now Giovanni ------------------------------------------------------------------------ [2002-11-25 16:19:31] [EMAIL PROTECTED] Could you please try the latest snapshot that will be avaliable from http://snaps.php.net in a few hours. It contains a fix that will make the code return a proper error message. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20526 -- Edit this bug report at http://bugs.php.net/?id=20526&edit=1
