Custom Query (8174 matches)
Results (70 - 72 of 8174)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #3561 | "Target file already exists" misses last slash in server's f | |||
| Description |
in dialog "Target file already exists" the last slash in the server's filename is missing e.g. transfer (overwrite) local c:\tmp\gaga.txt to /tmp on server the dialog asks Source file: C:\tmp\gaga.txt Target file: /tmpgaga.txt it should ask for /tmp/gaga.txt the last slash is missing (Version 3.0.11 Windows XP Prof ....) |
|||
| #9984 | rejected | "The server's certificate is unknown" using new version "FileZilla_3.10.0-rc2_win32-setup.exe" | ||
| Description |
Message -> "The server's certificate is unknown" with version "FileZilla_3.10.0-rc2_win32-setup.exe". It works okay using version "FileZilla_3.9.0.6_win32-setup.exe"
|
|||
| #3394 | "Too many connections" wrongly marked "Failed Transfer" | |||
| Description |
I set my "Maximum simultaneous transfers" to 8, the max my server can handle. However, for some reason a connection or two has been opened and not closed by Filezilla (probably another bug). At this point there are 6 existing hung connections, leaving me with 2 that should transfer. However, when I try to transfer a queue of files, two slots are used correctly, and any other files that try to use the other 6 connections get "421 Too many connections (8) from this IP", and are marked as "Failed Transfers". However, this is incorrect; they are not failed, there are simply not enough connections to transfer the files concurrently. This is the same situation if I then transfer files to another server that only handles 4 simultaneous connections. That means that any files using the 4 connections will succeed, but any that are *attempted* using the other 4 connections will be marked as "Failed Transfer", instead of simply waiting in the queue longer. This means I have to set the "Maximum simultaneous transfers" manually for *every* server I use, and then I have to keep an eye on the Failed Transfers log for any wrongly marked failures. Ideally, when filezilla gets the "421: too many connections" error while transferring more than one file at a time, it would simply keep that file on the queue and wait for the next available connection. This way a given max connections can be specified (say, 6) and if a server doesn't support that many the situation will be handled gracefully (all files will transfer, the max supported connections will be used) instead of how it is now (some files transfer, some don't). I have a verbose debug log available, if needed. Thanks! |
|||
