Custom Query (8143 matches)
Results (115 - 117 of 8143)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#10700 | rejected | Python Client failing to upload file to filezilla 0.9.53 | ||
Description |
A python 2.7 client was able to connect and upload files to my filezilla server 0.9.44 using the following:
However after updating the server to 0.9.53 we are able to establish a connection however, the file upload is failing. This is the updated python:
Traceback (most recent call last):
ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:581)
(000186)11/12/2015 20:38:48 PM - (not logged in) (xxx.xxx.xxx.xxx)> Connected on port 990, sending welcome message... (000186)11/12/2015 20:38:48 PM - (not logged in) (xxx.xxx.xxx.xxx)> SSL connection established (000186)11/12/2015 20:39:32 PM - (not logged in) (xxx.xxx.xxx.xxx)> USER xxxxxg (000186)11/12/2015 20:39:32 PM - (not logged in) (xxx.xxx.xxx.xxx)> 331 Password required for xxxxxg (000186)11/12/2015 20:39:32 PM - (not logged in) (xxx.xxx.xxx.xxx)> PASS (000186)11/12/2015 20:39:32 PM - xxxxxg (xxx.xxx.xxx.xxx)> 230 Logged on (000186)11/12/2015 20:39:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> PBSZ 0 (000186)11/12/2015 20:39:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> 200 PBSZ=0 (000186)11/12/2015 20:39:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> PROT P (000186)11/12/2015 20:39:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> 200 Protection level set to P (000186)11/12/2015 20:40:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> TYPE A (000186)11/12/2015 20:40:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> 200 Type set to A (000186)11/12/2015 20:40:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> PASV (000186)11/12/2015 20:40:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> 227 Entering Passive Mode (xx,xx,xx,xx,19,149) (000186)11/12/2015 20:40:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> STOR chrome_installer.log (000186)11/12/2015 20:40:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> 150 Opening data channel for file upload to server of "/chrome_installer.log" (000186)11/12/2015 20:40:45 PM - xxxxxg (xxx.xxx.xxx.xxx)> 450 TLS session of data connection has not resumed or the session does not match the control connection (000186)11/12/2015 20:44:45 PM - xxxxxg (xxx.xxx.xxx.xxx)> 421 Connection timed out. (000186)11/12/2015 20:44:45 PM - xxxxxg (xxx.xxx.xxx.xxx)> disconnected.
|
|||
#3914 | rejected | Downloaded large files are not removed from queue | ||
Description |
When downloading large files (1-2 GB) which take quite some time (e.g. several hours at 80 kB/s), they remain in the queue although they have been downloaded completely. Also, the connection seem to be still open. If I reopen Filezilla and press the "Q->" button, a short transfer will be initiated (about 1 kB) and the file is then successfully removed. This bug is annoying because the computer would not shut down over night, and if there are many of those files, other queue entries would wait forever for their turn. |
|||
#4068 | duplicate | Downloaded large files are not removed from queue | ||
Description |
Please see ticket: http://trac.filezilla-project.org/ticket/3914 This error appears to come from the server side. I'm working o a dedicated server and the timeout for inoperativity is set to 60 seconds (both options). When downloading a large file which will take more than 60 seconds (normally 1-2 hours), the server appears to have dropped silently the command channel. When the download eventually finishes, the server can't tell the client it has done so, thus the file remains in the queue. To fix this I believe it is necessary to keep the commend line up and connected as long as the file transfer is in progress. I've tried to disable the timeout, and then it works. |