Filezilla Client - can't resume file >2GB

[piovra78]

I have this situation:

Server: unbuntu 12.04 LTS, vsFTPd 2.3.5. (should support files >2GB since a long time)
Client: windows XP, filezilla 3.5.3 (should support files >2GB)
Settings: plain FTP with usr/pwd, server and client on the same LAN.

What happens: I can't resume files from server if they are >2GB.
I tried another client (WinSCP) and this doesn't happen. I can transfer the file if I don't interrupt it, the issue is just on resume.

Here the log:

16:19:26 Status: Connecting to 10.42.0.1:21...
16:19:26 Status: Connection established, waiting for welcome message...
16:19:26 Response: 220 (vsFTPd 2.3.5)
16:19:26 Command: USER *
16:19:26 Response: 331 Please specify the password.
16:19:26 Command: PASS *
16:19:26 Response: 230 Login successful.
16:19:26 Command: SYST
16:19:26 Response: 215 UNIX Type: L8
16:19:26 Command: FEAT
16:19:26 Response: 211-Features:
16:19:26 Response: EPRT
16:19:26 Response: EPSV
16:19:26 Response: MDTM
16:19:26 Response: PASV
16:19:26 Response: REST STREAM
16:19:26 Response: SIZE
16:19:26 Response: TVFS
16:19:26 Response: UTF8
16:19:26 Response: 211 End
16:19:26 Command: OPTS UTF8 ON
16:19:26 Response: 200 Always in UTF8 mode.
16:19:26 Status: Connected
16:19:26 Status: Retrieving directory listing...
16:19:26 Command: CWD /mnt/DATA/Scaricati
16:19:26 Response: 250 Directory successfully changed.
16:19:26 Command: PWD
16:19:26 Response: 257 "/mnt/DATA/Scaricati"
16:19:26 Command: TYPE I
16:19:26 Response: 200 Switching to Binary mode.
16:19:26 Command: PASV
16:19:26 Response: 227 Entering Passive Mode (10,42,0,1,101,248).
16:19:26 Command: LIST
16:19:26 Response: 150 Here comes the directory listing.
16:19:26 Response: 226 Directory send OK.
16:19:26 Status: Calculating timezone offset of server...
16:19:26 Command: MDTM Dummy.mkv
16:19:26 Response: 213 20120815152108
16:19:26 Status: Timezone offsets: Server: 0 seconds. Local: 7200 seconds. Difference: 7200 seconds.
16:19:26 Status: Directory listing successful
16:20:40 Status: Connecting to 10.42.0.1:21...
16:20:40 Status: Connection established, waiting for welcome message...
16:20:40 Response: 220 (vsFTPd 2.3.5)
16:20:40 Command: USER pio-mode
16:20:40 Response: 331 Please specify the password.
16:20:40 Command: PASS *
16:20:41 Response: 230 Login successful.
16:20:41 Command: OPTS UTF8 ON
16:20:41 Response: 200 Always in UTF8 mode.
16:20:41 Status: Connected
16:20:41 Status: Starting download of /mnt/DATA/Scaricati/BIGFILE.mkv
16:20:41 Command: CWD /mnt/DATA/Scaricati
16:20:41 Response: 250 Directory successfully changed.
16:20:41 Status: Testing resume capabilities of server
16:20:41 Command: TYPE I
16:20:41 Response: 200 Switching to Binary mode.
16:20:41 Command: PASV
16:20:41 Response: 227 Entering Passive Mode (10,42,0,1,209,121).
16:20:41 Command: REST 4431494699
16:20:41 Response: 350 Restart position accepted (4431494699).
16:20:41 Command: RETR BIGFILE.mkv
16:20:41 Response: 150 Opening BINARY mode data connection for BIGFILE.mkv (4478241540 bytes).
16:20:41 Response: 426 Failure writing network stream.
16:20:41 Error: Server does not support resume of files > 2GB.
16:20:41 Error: Critical file transfer error

I removed usr name and file name, all the rest is left untouched.
Access to the file is possible, I resumed a couple of times while it was still <2GB, an it worked perfectly.
I couldn't find any options for this case, and usually I just made a queue and process it in a go, so I never run in this.
I think it's a bug, may be not, just signaling it.

piovra78

[Tim Kosse]

What's the exact size of the file in bytes?

[piovra78]

Oh, well, actually I don't remember what that file was, maybe 7-8GB? Deleted since then, sry.
While I tried again on another file, I found that the issue only happens if the "source" file is in the process of being downloaded, not if I stop its download for example. So files >2GB can be transferred via Filezilla, but not if they are in the process of being written. Strange why it doesn't happen if file is <2GB.

[Tim Kosse]

In other words, the file size on the server has changed since the start of the transfer and the resume attempt?

[piovra78]

yes. size continues to change (becames bigger) as it is downloaded.
can be that filezilla detects this, while other clients don't.
so those clients resume ftp transfer, and transfer data till there is data avail.
maybe filezilla detects that the size change and gives the above output?

[Tim Kosse]

yes. size continues to change (becames bigger) as it is downloaded.

Hmm, that's interesting, never considered that before.