Bugs item #3076430, was opened at 2010-09-27 09:48
Message generated for change (Comment added) made by oernii
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3076430&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: SCP/SFTP
Group: bad behaviour
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ernest Beinrohr (oernii)
Assigned to: Daniel Stenberg (bagder)
Summary: SFTP resume with 4GB file does not work

Initial Comment:
I was trying to resume a file, part of which was downloaded with scp. The file is ~3.5GB large (3579444861) and the small part is
176521216 bytes. However, curl refuses to resume the file with the message:

curl: (36) Offset (176521216) was beyond file size (-715522435)

command line:
/usr/src/curl-7.21.1/src/curl -v sftp://user@server/backup/file.tar.bz2 -C - -o file.tar.bz2

curl version:
curl 7.21.1 (x86_64-unknown-linux-gnu) libcurl/7.21.1 OpenSSL/1.0.0a zlib/1.2.3 libidn/1.18 libssh2/1.2.5
Protocols: dict file ftp ftps http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: IDN Largefile NTLM SSL libz

PS: ever worse, if I leave out the '-C -' part, curl crashes :(

----------------------------------------------------------------------

>Comment By: Ernest Beinrohr (oernii)
Date: 2010-09-29 09:49

Message:
the patch works, it hits
curl: (36) Bad file size (-715522435)

PS: 2^32 - 715522435 = 3579444861 , so yes it hits, but the with
roll-overs you never know, it could be 2x 2^32-715522435 :(

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-29 09:38

Message:
So the patch's condition triggers?

We need to first know exactly what happens before we can consider
work-arounds. If the patch triggers it means the server is broken. If the
server is broken, we need to decide if we can figure out a decent way to
work around this flaw.

Your problematic case might be due to the server not supporting large
files properly, and I'm not at all certain that we can work around that
flaw in the client side.

Can you derive that negative file size somehow from the original actual
size? Is it -(4GB-file size) ?

----------------------------------------------------------------------

Comment By: Ernest Beinrohr (oernii)
Date: 2010-09-29 08:19

Message:
Well, I was hoping for a work-around :(

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-28 22:13

Message:
I just attached 'sftp-avoid-negative-file-size.patch' to this bug report.
It is an attempt to detect a negative file size at once and then bail out.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-28 06:55

Message:
Right, to me this looks like a bad server-end that responds with a weird
file size on the SFTP stat request. I'll soon provide you with a test patch
to allow us to see this in detail.

----------------------------------------------------------------------

Comment By: Ernest Beinrohr (oernii)
Date: 2010-09-28 06:50

Message:
my ssh: OpenSSH_5.5p1, OpenSSL 1.0.0a 1 Jun 2010
remote server: RHEL 5.5: OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul
2008

PS: against another ssh 5.5 it works

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-09-27 16:36

Message:
Do you know what server software and version is running in the other end?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3076430&group_id=976
Received on 2010-09-29