Skip to content
Advertisement

End of file error for phpseclib for any file get

I’m getting a NET_SFTP_STATUS_EOF: End of file error for any file downloaded from a particular SFTP Server using phpseclib. A similar question was asked here though I don’t think it has any resolution.

Oddly though, all the files seem to be importing correctly and with the same file size, however, the error is still produced and is making me slightly concerned as it is crucial these files are imported correctly.

I’m using the latest version of phpseclib and PHP 7.3. I’ve attached a the file I’m trying to download here (which does seem to download correctly but produces this error) and the SFTP dump using define('NET_SSH2_LOGGING', 3) here.

Any help for why phpseclib is producing this error would be much appreciated.

Advertisement

Answer

It’s not an issue.

phpseclib downloads files in chunks of 32kb. Each download request an SFTP client sends is followed up with a download response from the SFTP server. To speed things up phpseclib sends 32x download requests and then reads the 32x download responses. It turns out that this is faster than interleaving them (eg. send 1x download request and read 1x download response). This is configurable through the NET_SFTP_QUEUE_SIZE constant.

32kb x 32 = 1mb. So basically phpseclib sends download requests in batches of 1mb. If the file isn’t exactly between x mb – 32kb and x mb (Where x is a whole number) then the last batch of 32x download requests will be too many.

In theory phpseclib could look at the size of the file before downloading it so that the number of download requests for the last batch is exact but what if you’re downloading from a device? eg. /dev/null or /dev/urandom or whatever? At that point stat will say that the filesize is 0.

What phpseclib does, instead of looking at the filesize, is that it reads until the response isn’t a download response but instead a download “status”. eg. “end of file”.

I could go on as to why the download requests are 32kb vs another size or why only 32x are downloaded at a time (vs. 64 or whatever) but, sufficient to say, this is the expected behavior and it’s nothing to be alarmed about.

User contributions licensed under: CC BY-SA
1 People found this is helpful
Advertisement