Custom Query (8174 matches)

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

In the progress bars that appear when uploading/downloading, it appears that the windows "highlight" color is used for the bar itself.

The percent (as text) seems to be using the windows foreground color. When the highlight passes over the text, the text seems to to white.

The problem with this is that if the user uses a light color for the highlight, it becomes difficult (if not impossible) to see the text.

Ideally, if the highlight color is used for the bar, then the Windows foreground color should be used as the text. (The idea here is the user will have already picked colors that have good contrast.)

The rule here should be that if using a color from the windows scheme for one part of a control, then windows colors should be used consistantly throughout the rest of the control.

We have setup FileZilla to limit the locat ports from 3000 to 3010.

We are invoking the upload from the command line.

filezilla -u "c:\download\db2_full.ftm" UserID:Password@IPAddress:990/QSYS.LIB/TESTPRFIL.LIB/M ON5099PF.FILE -t M20060623.MBR -overwrite

One time the transfer will work correctly the next time it will first fail to connect and on the second attempt it will connect correctly.

Sample Log file: Status: Connecting to 172.23.164.17:990 ... Trace: FtpControlSocket.cpp(5140): m_pSslLayer changed state from 0 to 1 caller=0x003b8174 Trace: FtpControlSocket.cpp(5140): m_pSslLayer changed state from 1 to 2 caller=0x003b8174 Trace: FtpControlSocket.cpp(5140): m_pSslLayer changed state from 2 to 6 caller=0x003b8174 Trace: FtpControlSocket.cpp(990): OnConnect(10048) OpMode=1 OpState=-1 caller=0x003b8174 Trace: FtpControlSocket.cpp(1129): DoClose(0) OpMode=1 OpState=-1 caller=0x003b8174 Trace: FtpControlSocket.cpp(3975): ResetOperation (4100) OpMode=1 OpState=-1 caller=0x003b8174 Error: Unable to connect! Status: Connecting to 172.23.164.17:990 ... Trace: FtpControlSocket.cpp(5140): m_pSslLayer changed state from 0 to 1 caller=0x003b8174 Trace: FtpControlSocket.cpp(5140): m_pSslLayer changed state from 1 to 2 caller=0x003b8174 Trace: FtpControlSocket.cpp(5140): m_pSslLayer changed state from 2 to 4 caller=0x003b8174 Trace: FtpControlSocket.cpp(990): OnConnect(0) OpMode=1 OpState=-1 caller=0x003b8174 Status: Connected with 172.23.164.17:990, negotiating SSL connection... Trace: SSL_connect: SSLv3 read server hello A Trace: SSL_connect: SSLv3 read server certificate A Trace: SSL_connect: SSLv3 read server done A Trace: SSL_connect: SSLv3 write client key exchange A Trace: SSL_connect: SSLv3 write change cipher spec A Trace: SSL_connect: SSLv3 write finished A Trace: SSL_connect: SSLv3 flush data Trace: SSL_connect: SSLv3 read finished A Trace: Using TLSv1, cipher TLSv1/SSLv3: RC4-MD5, 1024 bit RSA Status: SSL connection established. Waiting for welcome message... Trace: FtpControlSocket.cpp(812): OnReceive(0) OpMode=1 OpState=-1 caller=0x003b8174 Response: 220-QTCP at CARSTEST. Trace: FtpControlSocket.cpp(812): OnReceive(0) OpMode=1 OpState=-1 caller=0x003b8174 Response: 220 Connection will close if idle more than 5 minutes. Command: USER mnmcrftp Trace: FtpControlSocket.cpp(812): OnReceive(0) OpMode=1 OpState=0 caller=0x003b8174 Response: 331 Enter password. Command: PASS Trace: FtpControlSocket.cpp(812): OnReceive(0) OpMode=1 OpState=3 caller=0x003b8174 Response: 230 MNMCRFTP logged on.

Any help resolving this issue would be appreciated.