ID: 20526 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: FTP related Operating System: MS Windows XP Pro PHP Version: 4.3.0RC1 New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2002-11-25 05:41:39] [EMAIL PROTECTED] Tried http://snaps.php.net/win32/php4-win32-latest.zip with same result. One of my reasons to suspect it is a bug is that the problem reported by PHP (FTP server reports 227), in my opinion, should not indicate an error at all. I am now trying to arrange a debug session by myself (I just downloaded Cygwin, PHP sources and other stuff suggested in the PHP manual, but this is for me quite a challenge, since I got somewhat rusted with software development :-) Wish me good luck... Ciao. Giovanni ------------------------------------------------------------------------ [2002-11-24 12:53:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip Cannot replicate the problem on WinXP or Linux with a variety of FTP servers. ------------------------------------------------------------------------ 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
