Is this bug still present to you, also with 4.1.0?

If so, can you verify that the 'hang' time is about 90 seconds (its a fixed coded timeout value in ext/ftp)?

Yes I've tested it with 4.1.1 and the problem ist still present. 90 Seconds is absolutly true! In this time he hangs in the ftp_rawlist function... and then he will continue, but often doesn't work the next call to ftp_rawlist too. And sorry, it isn't a problem of the user, but when executing per CLI, the script run more reliable than executed by apache. When I start the script directly it run sometimes until end (Not often). 

I tested it on 2 machines (W2K-Notebook and W2K-PC). 

I'm very intrested in this function, because i'm working on a little web-filesharing-tool, which should index content of ftps. Thanks for your feedback!

I'm setting this to open, version to 4.1.1. Although in CVS there exists now a way to adjust the timeout (ftp_set_option(FTP_TIMEOUT_SEC, 10); for example) it's not a solution and there are still some flaws in the implementation IMO.

Please update version :)

Having the same problem here with WinXP proffesional
version 4.1.1

from my experience it seems it sends the "list" command.
then my FTP server (UNIX: type L8) receives it properly and
answers with the data being send in ASCii mode. and
then it hangs and i actually have to reboot for it to work
another time. It just won't interprete the script anymore
for a second there it allmost seems as if it needs to flush or waits for a timeout to occur.

I had the same problem with linux and PHP 4.1.1.

In my opinion there's a problem in line 886 of file ext/ftp/ftp.c. I replaced

memmove(ftp->inbuf, ftp->inbuf+4, FTP_BUFSIZE-4);

with

memmove(ftp->inbuf, ftp->inbuf+4, FTP_BUFSIZE-4);
if (ftp->extra)
    ftp->extra -= 4;

The execution of memmove drops 4 bytes of the last response text which is stored in ftp->inbuf. In case of ftp->extra != NULL, there are extra characters and 4 characters of the next response are lost if you don't adjust ftp->extra.

This is still an issue.

Find below a test script which does a recursive directory listing of a FTP server.

This hangs on ProFTPd (Tested on >1.2.2) for the timeout period every so often on the ftp_rawlist (It seems mostly to be empty directories, but not always) but will usually continue working on the second or third retry.

It seems OK on other FTP servers, but I've not been able to really test this.

The FTP server logs indicate that the LIST has finished and has been transmitted.

The fix by resolves this issue, I will post a patch against 4.3.0-dev in a seperate comment.

===============================

<?
  $ConnId = ftp_connect( "localhost" );
  $LoginId = ftp_login( $ConnId, "carl", "passwd" );

  if ( !$ConnId || !$LoginId ) {
    echo "Login failed!\n";
    die();
  }

  ftp_pasv( $ConnId, true );

  function doDirectory( $Path, $Depth ) {
    global $ConnId;

    echo str_repeat( " ", $Depth );
    echo "'$Path'\n";

    ftp_chdir( $ConnId, $Path );
    unset($ThisPath);
    $i = 1;
    while ( !is_array( $ThisPath ) ) {
      $ThisPath = ftp_rawlist( $ConnId, "-al" );
      if ( !is_array( $ThisPath ) ) {
        echo str_repeat( " ", $Depth+2 );
        echo "*** Error, Retrying ".($i++)." ...\n";
      }
    }

    foreach( $ThisPath AS $Entry ) {
      if( ereg( "([-d])[rwxst-]{9}.* ([0-9]*) [a-zA-Z]+ [0-9: ]*[0-9] (.+)", $Entry, $Bits ) ) {

        if ( $Bits[3] == "." || $Bits[3] == ".." ) {
          continue;
        }

        if ( $Bits[1] == "d" ) {
          doDirectory( $Bits[3], $Depth+2 );

        } else {
          echo str_repeat( " ", $Depth+2 );
          echo $Bits[3]."\n";

        }

      } ## Matches the ereg?

    } ## Iterate directory entries

    ftp_chdir( $ConnId, ".." );

  } ## End doDirectory()

  doDirectory( "", 0 );
?>

Here is the aforementioned patch ...

======================

Index: ftp.c
===================================================================
RCS file: /repository/php4/ext/ftp/ftp.c,v
retrieving revision 1.49
diff -u -r1.49 ftp.c
--- ftp.c       18 Mar 2002 22:26:32 -0000      1.49
+++ ftp.c       3 Jul 2002 15:28:36 -0000
@@ -919,6 +919,8 @@
                        (ftp->inbuf[2] - '0');
 
        memmove(ftp->inbuf, ftp->inbuf + 4, FTP_BUFSIZE - 4);
+  if ( ftp->extra )
+               ftp->extra -= 4;
 
        return 1;
 }

This bug has been fixed in CVS. You can grab a snapshot of the
CVS version at http://snaps.php.net/. In case this was a documentation 
problem, the fix will show up soon at http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites.
Thank you for the report, and for helping us make PHP better.

Patch applied.