Custom Query (8073 matches)


Show under each result:

Results (118 - 120 of 8073)

Ticket Resolution Summary Owner Reporter
#12579 invalid version 3.56 minimum TLS version setting stuck at "2" Thomas Kite Sharpless
  1. 3.56.2 pulls 'Gnu TLS error -8: unsupported version" when connecting to a site whose highest active TLS version is 1.2. filezilla.xml has this:
3.56.0-rc1 (2021-09-29)

+ Right-clicking a queue tab header now opens the same context menu as right-clicking the correponding queue contents
+ By default, the minimum allowed TLS version is now TLS 1.2
+ Optionally, the systen trust store can be used for certificate verification
- FTP: Fixed an issue with key file conversion
- Fixed an issue loading servers not supporting session resumption from storage
		<Setting name="Window position and size">0 306 14 1402 924 </Setting>
		<Setting name="Minimum TLS Version">2</Setting>
		<Setting name="Trust system trust store">0</Setting>
		<Setting name="Greeting version">3.56.2</Setting>

The line for Minimum TLS Version is clearly in error -- surely this should be "1.2" not "2". Worse, when I make that change and run FileZilla, the number reverts to "2".

#12572 rejected When update to v.3.56.2 cannot view local folder on the left side. Mediateh Pleven

Workaround: Drop files from Windows Explorer into remote server folder on the right.

FileZilla Client

Version: 3.56.2

Build information:

Compiled for: x86_64-w64-mingw32 Compiled on: x86_64-pc-linux-gnu Build date: 2021-10-27 Compiled with: x86_64-w64-mingw32-gcc (GCC) 10-win32 20210110 Compiler flags: -O2 -g -Wall -Wextra -Wno-deprecated-copy -ffunction-sections -fdata-sections -Wno-cast-function-type

Linked against:

wxWidgets: 3.0.6 SQLite: 3.35.5 GnuTLS: 3.7.2

Operating system:

Name: Windows 7 (build 7601, Service Pack 1), 64-bit edition Version: 6.1 Platform: 64-bit system CPU features: sse sse2 sse3 ssse3 sse4.1 sse4.2 avx aes pclmulqdq rdrnd lm Settings dir: C:\Users\Valeri\AppData\Roaming\FileZilla\

#12570 fixed changed behavior RETR on nonexisting file Sebastian

In FileZilla Server 1.1.0 the behavior changed if a client sends an RETR for a nonexistant file.

behavior prior to version 1.1.0:

RETR file_that_does_not_exist 550 No such file

behavior in version 1.1.0:

RETR file_that_does_not_exist 150 Starting data transfer. 425 Error reading from file: 5

this is a big problem, because our clients (not our software) make RETR until a service on that server created this file. with the new responses the clients send a quit after they get the 425

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.