I lost many hours over this too and, fortunately, I found the problem.
There’s a conceptual bug. The engineer who wrote class-ftp-sockets.php
pretends to read at most ONE line on the FTP Control Session, after each request (FTP Command), this works in most cases, but not always.
In our case, when we do a “LIST -la” (follow dirlist function) the FTP server (Pure-FTP) answers with something like this:
150 Accepted data connection
226-Options: -a -l
226 3 matches total
Now, take a look in _readmsg function (class-ftp-sockets.php):
$tmp=@socket_read($this->_ftp_control_sock, 4096, PHP_BINARY_READ);
It tries to read 4K of data, no matter if one or many lines, then
it tries to extract the FTP Server Reply Codes through regular expression:
$go = !preg_match("/^([0-9]{3})(-.+\\1)? [^".CRLF."]+".CRLF."$/Us", $this->_message, $regs);
BUT the previous pattern will match if and only if the string is a LINE, if not, thinking that we are in presence of a partial line, it tries to read again appending new incoming data in order to complete the LINE. Unfortunately, there is nothing to read and it fails with “Resource temporarily unavailable” message.
_readmsg fails => _exec fails => _list fails => rawlist fails => dirlist fails => array_keys FAILS!
_readmsg is called by _exec every time we do a FTP command:
$status=@socket_write($this->_ftp_control_sock, $cmd.CRLF);
if($status===false) {
$this->PushError($fnction,'socket write failed', socket_strerror(socket_last_error($this->stream)));
return FALSE;
}
$this->_lastaction=time();
if(!$this->_readmsg($fnction)) return FALSE;
Between socket_write and _readmsg we can’t know how many lines the FTP Server has flushed out on the ftp control stream then, we cannot assume to read at most ONE line or partial line.
At this point, a buffered reader seems to be necessary.
NOTE: I have this problem only in one server, on the others all works fine.
