Custom Query (8022 matches)

There are integer overflows in enging/directorylistingparser.cpp and interface/remotelistview.cpp, when converting from the string received to int64_t. A number higher than the max of int64_t as the size returned in a directory listing will be improperly parsed and produce nonsensical results, such as a negative file size.

This happens on lines 220, 2644, and 2665 in directorylistingparser and 782 in remotelistview (not an exhaustive list).

Since this value is not used, other than displayed to the user, I do not think this can be exploited, nor crash the program.

The following bug has appeared today, immediately after I had upgraded Filezilla to version 3.48.0. It didn't happen with previous versions (I have been using FZ daily for years --- thank you for creating this wonderful tool).

Now, whenever I doubleclick a LOCAL file in order to edit it, I get an error message popup reading "Opening failed: The file '[FILENAME HERE]' could not be opened: The associated command failed" (+ OK button). This is a spurious error message, as the file does open just fine. This happens with every local file I try to edit, forcing me to close this popup on every local file edit (a very common occurrence for me). It does not happen with files on the server.

My relevant settings are:

• File lists -> Double-click action on files -> View/Edit
• File editing -> Default editor -> use custom editor -> "C:\Program Files (x86)\Vim\vim74\gvim.exe"
• File editing -> Always use default editor

Additional observation:

• If instead of double clicking the local file, I right click it and select "Edit" the same error appears. However, if I select "Open" it does not.

P.S. Also posted this on the forum.

I have tried putting the path in file associations but it doesnt work transfers to somewhere_{,I dont know where tho. Its many different pdfs, not just one. If I dont specifiy a path in file associations it tries to load in my default which is notepad++}