FTP to upload.sf.net fails consistently for large files

[pombredanne]

I am having that persistent problem with large file
updaloads to Sf.net File Release System.
I have had it for ever, including on the current latest
release 2.2.25
It happens consistently for files that are above
~150MB, regardless of the connection I have (I tried it
with ADSL, SDSL, Cable and T1) and the machine I use
(typically winxp pro or home).

A queue ends up with a critical transfer error :-\
No problems with smaller files.
And no problem when I use a command line FTP client on
a mac.
I use the deafults settinsg and a single connection for
upload, with nothing else running on the machine at
that time.
A typical log looks like that. And note that the file
DID NOT exists before the updalod in the FRS .

16:56:13] Status: Connecting to upload.sourceforge.net ...
[16:56:13] Status: Connected with
upload.sourceforge.net. Waiting for welcome message...
[16:56:13] Response:
220-
[16:56:14] Response: 220- SourceForge.net FTP server -
San Jose (osdn.dl.sourceforge.net)
[16:56:14] Response: 220- Additional access is at
​http://osdn.dl.sourceforge.net/pub/mirrors/
[16:56:14] Response: 220- Mirrors, try 'rsync
osdn.dl.sourceforge.net::'
[16:56:14] Response: 220-
[16:56:14] Response: 220- Got a fat pipe and something
to prove? Host a SourceForge download
[16:56:14] Response: 220- server! Email
ftpadmin@… for opportunities.
[16:56:14] Response: 220-
[16:56:14] Response: 220- On This Site:
[16:56:14] Response: 220- /incoming

SourceForge.net Project File Upload

[16:56:14] Response: 220-
*
[16:56:14] Response: 220
[16:56:14] Command: USER anonymous
[16:56:15] Response: 331 Please specify the password.
[16:56:15] Command: PASS
[16:56:15] Response: 230 Login successful.
[16:56:15] Command: SYST
[16:56:16] Response: 215 UNIX Type: L8
[16:56:16] Command: FEAT
[16:56:16] Response: 211-Features:
[16:56:16] Response: EPRT
[16:56:16] Response: EPSV
[16:56:16] Response: MDTM
[16:56:16] Response: PASV
[16:56:16] Response: REST STREAM
[16:56:16] Response: SIZE
[16:56:16] Response: TVFS
[16:56:16] Response: 211 End
[16:56:16] Status: Connected
[16:56:16] Status: Starting upload of
D:\e\plugin-releases\easyeclipse-desktop-java-1.2.0.tar.gz
[16:56:16] Command: PWD
[16:56:17] Response: 257 "/"
[16:56:17] Command: CWD /incoming/
[16:56:17] Response: 250 Directory successfully changed.
[16:56:17] Command: PWD
[16:56:17] Response: 257 "/incoming"
[16:56:17] Command: TYPE A
[16:56:17] Response: 200 Switching to ASCII mode.
[16:56:17] Command: PASV
[16:56:18] Response: 227 Entering Passive Mode
(66,35,250,221,233,53)
[16:56:18] Command: LIST
[16:56:18] Response: 150 Here comes the directory listing.
[16:56:18] Response: 226 Transfer done (but failed to
open directory).
[16:56:18] Command: TYPE I
[16:56:19] Response: 200 Switching to Binary mode.
[16:56:19] Command: PASV
[16:56:19] Response: 227 Entering Passive Mode
(66,35,250,221,230,167)
[16:56:19] Command: STOR
easyeclipse-desktop-java-1.2.0.tar.gz
[16:56:19] Response: 553 Could not create file.
[16:56:19] Error: Upload failed
[16:56:50] Status: Disconnected from server

[Tim Kosse]

[16:56:19] Response: 553 Could not create file.

This looks like a problem with the server. It is possible
that a previous transfer got interrupted. Since the server
doesn't allow listing of this directory, it shows up as
empty. Yet server also disallowed overwriting files, leading
to this error message.
It might help to increase the timeout value in the settings.

[pombredanne]

I am reopening this bug, I still experience it.
Interestingly the mac os command line client (which uploads
fine) enter something called "extended passive mode"..
I have no idea what that is, but that may be part of the
solution?

[Tim Kosse]

What's your timeout value set to? What happens if you double it?

[sf-robot]

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

[pombredanne]

I played with timeouts from 300 seconds up to 999 seconds.
The problem is always the same.

[Alexander Schuch]

Can you please test current version of FileZilla 3 and report back if the problem is solved for you or if it still persists?
Much has changed between FileZilla 2 and FileZilla 3, so chances are that the problem might be fixed.

[sf-robot]

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).