Hi everyone!

I thought I'd toss a question/issue report up a bit in the air.
As I'm not exactly sure about what is the exact source/cause of the
issue is, I'll start with it here, but it might very well be better
suited for the LibSSH2 mailing list.

I just updated our SFTP module with a bit of new functionality, and
during this update I thought I'd make sure to rebuild our libcurl dll,
together with all it's components to the latest versions. This was a
lift from quite old versions of libcurl, libssh2 and openssl. The new
versions I tried to build using was the latest stable of all of them,
libcurl 7.21.6, libssh2 1.2.8 and openssl 1.0.0d. Furthermore, I decided
to throw in zlib 1.2.5 which I hadn't used in the previous builds.

All of this is Win32 builds, and my runtime environment is currently
Win7 x64. Also of interest might be that this is using the easy interface.

When reaching the end of the build, and starting to test out the new
dynamic libraries, I quickly encountered the issue this is about; for
files with a size slightly above 700kB, I receive CURLE_PARTIAL_FILE as
return code.

This seems to be quite random in the interval of 730-750 kB, where I
think 743kB is roughly 50/50 chance of getting CURLE_OK or
CURLE_PARTIAL_FILE. The smaller the file, the more likely to receive
CURLE_OK, and the larger the file the more likely to receive
CURLE_PARTIAL_FILE. I'm not sure if this varies for different
environments or with different optimization levels; I've only done the
tests with file size using debug builds of all components involved.

I've also tried with all sorts of files and sizes, ASCII files, binary
files, and files up to 1.8GB size. The magic number as said, seems to be
roughly 740kB, and the verbose info when returning from the easy_perform
gives values of between 1,5kb up to 12kb left to fetch, with most common
values between 2kB and 6kB.

This has been tested against an OpenSSH sshd, as well as Core FTP
mini-sftp-server, and the same behavior for both.

Since the initial build, I managed to spend a bit of time to pinpoint
the component it stems from, which seems to be the last version of
libssh2. With curl 7.21.6, compiled, and linked at run time, against
libssh2 1.2.7 the issue is nowhere to be found. As soon as I tick this
up to version 1.2.8 however, I immediately find the CURLE_PARTIAL_FILE
issue as described.

Is this an known issue, or is it a undocumented bug? It feels like it
might be quite related to the read/write rewrite of libssh2, and I'm not
sure if this is something that curl needs to be adapted to (even though
I suspect that it already would have been if that was the case,
considering the quite well coordinated development)?

Any experiences, ideas, questions, feedback that might lead in the right
direction very welcome. :)
Next step on my way, I thought, is to see if the behavior is the same
with the command line tool.

Best regards
Patrik Thunström / patrik.thunstrom_at_bassetglobal.com

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-05-23