On Mon, 29 Oct 2007, Jeff Vincent wrote:

> I'm new to this list and have tried searching the archives for my issue but
> without success. I am debugging an app (that I didn't write) that uses
> libcurl for FTP support. When copying against a Windows 2000 Server running
> the latest service packs (sp4) and using the MS IIS FTP server I am getting
> some weird behavior. I can't find anything to tell me there is a problem
> with the MS FTP server or that it behaves differently than other FTP server
> implementations.

Can't you just run your application against other FTP servers and check for
differences?

> Sometimes the destination file is truncated and sometimes it disappears. I
> used WireShark to get a packet trace and it seems that for some unknown
> reason, the MS FTP server (or the TCP stack on the FTP server) sends a RST
> and closes the connection. Sometimes this happens in conjunction with the
> FTP message 426 - Transfer aborted.

That sounds like a severly broken server.

> In both cases, it seems that the FTP server is cleaning up what it thinks is
> an incomplete file transfer and deleting the partially copied file. I don't
> think this is a configurable option.

Then I would advice you to select another FTP server. There are numerous fine
ones that are entirely free and gratis and open.

> In one case, cURL recognizes a partial transfer and attempts to resume the
> transfer by starting the copy where it left off and appending to the file
> (APPE as seen in the packet trace). Since the server deleted the partial
> transfer, the result is a truncated file. cURL then reports success.

Note that this concerns curl the tool, if you use the --retry option. This
isn't done by libcurl itself.

This can possibly be seen as a bug, but I would also argue that this is an odd
server...

> I have enabled all tracing (which the developer has noted is all or
> nothing),

You mean in libcurl? Then it's not quite "all or nothing" if you use the
DEBUGFUNCTION, but I guess that's not really the point here...

> but I am unable to see cURL handling the RST or 426 conditions in the log
> file so am unable to determine what cURL thinks is happening.

In FTP land, the end of a transfer is indicated by a closed connection so a
prematurely cut off connection can be hard to detect as a failure. It will
thus depends on the following status line to properly tell.

> Are there known issues with the MS FTP server or does anyone have
> suggestions on any options or ways to debug what is happening on either side
> that could help?

I'm not aware of any known issues with the MS FTP server, but I also can't
claim to know many people who use that or who use libcurl against of those.
And as I said before, I really can't see any reason for anyone to use that
server either...

I would say that to track this down you should start checking the server side:
why does it suddenly break the connection and why does it not like the
operation in progress? You can easily verify with RFC959, the libcurl source
code, another ftp server and wireshark that libcurl is behaving correctly.

How to check and fix the FTP server is not my game though.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html