Custom Query (8097 matches)
Results (166 - 168 of 8097)
|#12824||fixed||1.6.0-rc1 error message at admin interface startup|
<Date> Info [Type] Message <30-11-2022 16:00:42> Admin UI [Error] The server appears to be behind a NAT router. Please configure the passive mode settings and forward a range of ports in your router.
The message above should not be [Error], it should be [Info] or [Notice].
|#73||1.8 pasv mode freaking out ftp servers|
When i try to upload with 1.8 in passive mode, i get an error:
Status: Starting upload of c:\Program Files\FileZilla\license.txt Command: TYPE A Response: 200 Type set to A. Command: PASV Response: 227 Entering Passive Mode (12,x,2,11,56,16). Command: STOR license.txt Error: Transfer channel can't be opened. Reason: The requested address is not valid in its context. Error: Upload failed
On the logs for my ftp server (g6) i see:
(17:42:41 - -0.001 KB - 0.000 KBytes/s).
Compared with 1.7b (which works), there was no PASV command issued after STOR. It just goes straight to "data connection." That has to be the reason it's messing up.. right?
I tried it real quick to upload to a proftpd server and i got the same error.
I hope it's not just me.
|#657||100% CPU usage and lock-ups while resuming large downloads|
Upon resuming an FTP download of a large file, Filezilla takes up 100% of CPU usage on Windows 98 SE, and mouse pointer movement gets extremely sluggish. After the connection is established, all returns to normal. If the download fails, Filezilla will retry the connection, and upon resuming it again the problem happens again but worse: the system seems to lock up completely for about 60 seconds (sometimes more, sometimes less). Most of the times, the connection is established and the system becomes responsive again after that lock-up period, but sometimes the lock-ups require a hardware reset.
If more than one large file are being downloaded, the lock-up caused by one transfer can make the others fail, so that they in turn lock the system up and make the first resumed download fail too.
This only happens when the resume position (the parameter for the RSET command) is large enough. Resuming the download of a large file on a position near zero doesn't cause any lock-up.
I guess (without looking at Filezilla's source) that there's some blocking call being made while Filezilla waits for the remote server to seek() to the RSET position.
In case that this be a server-dependent bug in Filezilla (I don't think it is), here's an example: I've experienced this problem while downloading the Mandrake distribution from many of the USA mirrors (for example, http://www1.mandrakelinux.com/ftpredir.php?url=ftp://mirror.cs.wisc.edu/pub/mirrors/linux/Mandrakelinux/official/iso/10.0/i586&tpc=mirrors-iso-Mandrakelinux-10.0-Official-inst-i586.txt ). This is a 700 Mb file. And for the record, Filezilla was run on a 400 Mhz AMD K6-3 processor.