Custom Query (8170 matches)
Results (493 - 495 of 8170)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #8329 | fixed | PAPERCUT: Updating wizard's "back" button is never active | ||
| Description |
LOCATION Updating wizard is accessible via "Main menubar/Help/Check for Updates..." ISSUE Possible redundancy in user interface. The FileZilla update wizard has a set of Back/Next buttons in the bottom of the wizard dialog box. As far as I can tell, "Back" button is never active. i.e. it is "grayed out" in all the steps of updating process. SOLUTION SUGGESTION If "back" button really is not accessible at any moment during the updating process, perhaps it should be removed. This would imply another question: Is "wizard" approach to updating is the best one. NOTE This papercut is present both on WinXP and OSX FileZilla Client versions. |
|||
| #8344 | fixed | Focus the last directory when navigating to it's parent | ||
| Description |
Now when filezilla goes up to a parent directory it selects the ".." entry instead of the directory we are coming from. It should select and focus the directory its coming from and make sure it's visible. This ticker is related to #1878 I've coded up a solution that implements this behavior. Patch attached against latest svn trunk (r4847) |
|||
| #8356 | fixed | Can't connect to Windows Server 2012 (IIS 8) FTP when using FTPES | ||
| Description |
Using FileZilla, I cannot connect to any of my Windows Server 2012 machines when using FTPES on IIS 8. FileZilla 3.6.0.2 debug level 4 log: Trace: CControlSocket::DoClose(64) Trace: CControlSocket::DoClose(64) Status: Resolving address of mysite.mydomain.com Status: Connecting to 1.1.1.1:21... Status: Connection established, waiting for welcome message... Trace: CFtpControlSocket::OnReceive() Response: 220-Microsoft FTP Service Trace: CFtpControlSocket::OnReceive() Response: 220 MyFtpService Trace: CFtpControlSocket::SendNextCommand() Command: AUTH TLS Trace: CFtpControlSocket::OnReceive() Response: 234 AUTH command ok. Expecting TLS Negotiation. Status: Initializing TLS... Trace: CTlsSocket::Handshake() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnSend() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::OnRead() Trace: CTlsSocket::ContinueHandshake() Trace: CTlsSocket::Failure(-110, 10053) Error: GnuTLS error -110: The TLS connection was non-properly terminated. Trace: CTlsSocket::OnSocketEvent(): close event received Trace: CRealControlSocket::OnClose(10053) Trace: CControlSocket::DoClose(64) Trace: CFtpControlSocket::ResetOperation(66) Trace: CControlSocket::ResetOperation(66) Error: Could not connect to server Trace: CFileZillaEnginePrivate::ResetOperation(66) I have already tried reordering cipher suites as desribed here, but it didn't help: http://blogs.msdn.com/b/kaushal/archive/2011/10/03/taming-the-beast-browser-exploit-against-ssl-tls.aspx Changing certificates on the FTP site doesn't help as well. I think the error happens before certificate is received. WS_FTP and some other FTP clients work fine, while WinSCP makes a connection but throws errors on file transfer (something about invalid signature). It did help with file transfers when I prioritized TLS_RSA_WITH_RC4_128_SHA on the server SSL Cipher Suite Order. It is worth noting that a version of FileZilla from a few weeks ago (I don't know which one exactly) connected fine, but was not able to transfer files (also a lot of errors), exactly what WinSCP does now. Connecting to my Windows Server 2008 R2 (IIS 7.5) machines works perfectly. FTP sites are configured the same way as they are in the IIS 8 installation. |
|||
