On Tue, 9 Dec 2003, Dave Meyer wrote:

> The ftp server that I'm communicating with supports the REST command,
> although it has slightly broken support (in my opinion), in that when curl
> asks for REST with a file offset larger than 2 GB, the server responds
> saying that's OK, but that it's going to resume the download starting at
> 2^32 - 1 bytes into the file, regardless of what offset larger than 2 GB I
> use.

Eeek. That surely is a nasty behavior that isn't mandated by anything in
RFC959. REST is supposed to set the restart position, and the server sends 350
to acknowledge the request.

Out of curiosity, what server is this?

> Here I should note that I'm using a patched version of curl which I've
> modified to support files larger than 2 GB, but that I've witnessed the same
> behavior with other ftp clients connecting to this server.

I'm hoping to see the 2GB patch applied soonish, so we'll all be able to face
this problem in the near future...

> > SIZE nt.gz
> < 213 2825135408
> * Instructs server to resume from offset 2825135000
> > REST 2825135000
> < 350 Restarting at 2147483647. Send STORE or RETRIEVE to initiate
> transfer

> From my browsing of the code, it doesn't appear that curl pays attention to
> the actual response information from the ftp server for the REST command --
> it only watches the response code.

Right, since I've been totally unaware of any server doing this craziness. And
does it really start at the position it claims it starts at or is it just an
output flaw?

> If I'm missing something, I would appreciate a prod in the right direction
> for handling this. If not, I was wondering whether it would make sense to
> work on something to support broken ftp servers like this. Certainly if I
> restart at the 2 GB boundary I can get the rest of the file (assuming my
> transfer isn't interrupted), so it seems like this might be a useful thing
> for dealing with broken servers, rather than just detecting the condition or
> saying that REST isn't supported beyond 2 GB...

First, we should verify that the server actually restarts at the position it
claims it does.

Then, I figure we can attempt to find the restart position by parsing the
response string for an exact match of the text you get. It should be pretty
harmless, as if the full text matches, the position should be correct, even if
another server would output the text in the exact same way.

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click