Major regressions over the past year

[winzilla]

This issue probably isn't as specific as might be desired, but I feel obligated at this point to report this to the project.

I have been using FileZilla for many many years. Throughout the past year, the performance and usability of FileZilla has decreased significantly. It has gotten to the point where it has become a significant impediment to doing work, since I SFTP files very regularly in order to do work. Several major regressions have been introduced into the software in the past few months/past year or so, for example:

1) Permanent hangs. If you leave a tab alone for a while and then come back to it, after it has timed out, and then try to navigate on the server, it just will not. With synchronized browsing, you can try to navigate different folders and it will just whine "synchronized browsing operation already in progress" and never complete. If you try closing the tab, it will prompt for confirmation and then the dialog for creating a directory that isn't synchronized comes up, which is obviously completely out of place and wrong. Very messed up.

TL;DR - often times, if a session becomes "stale", then it is stuck that way and can't become "unstale" - you have to start ALL over.

Changing the timeout in settings from 20 to 0 has no effect.

The solution is to open an entirely new tab and then re-navigate to the path you were at. The new tab opens and connects instantly. However, this is very annoying as if you manually changed paths, you now have to find your way back to where you were, and when you have to do this dozens of times per day, that wastes A LOT of time. It got to the point where it was faster to just come back to FileZilla and open a new window and start all over again rather than trying to bother recovering the previous session.

2. Infinite loops. There are serious bugs in the software that can cause infinite loops. On multiple occasions, CPU usage has gone to 100%, even after FileZilla was closed, and it turned out to be filezilla.exe consuming 100% of CPU. Clearly something went very wrong, as even when closing the window the process didn't exit as I told it. This doesn't happen super frequently, but it's happened enough times to be vexing.

3. Corrupted transfers. Quite frequently, on certain servers especially, file transfers get truncated at some multiple of 256 bytes, and I might have to retry the transfer 2, 3, 4, 5, 6, 7, 8 etc. times before the entire file actually fully copies. (FileZilla does correctly show the transfer "failed").

As a result, I have been wasting 15+ minutes PER DAY just because of how broken FileZilla has become in the past year.

I have been able to notice the difference because I have been upgrading FileZilla normally on one system and I have a static copy of FileZilla Portable 3.44.1 on another system, from 2019. That system never has any issues, but the up-to-date one just gets worse and worse.

Today, I downgrade from the latest version that I had (3.60.1) to 3.44.1 and immediately noticed the difference. No hangs. No freezes. No issues. The software JUST WORKS as it used.

And then of course, a pop up comes up saying it's automatically downloaded 3.60.1 to the Downloads folder. No thanks - modern versions of FileZilla are no longer suitable for production usage. FileZilla has become so unusable these days I can't even stand it. As 3.44.1 works fine, I'll be using that indefinitely forever unless these issues are all resolved, as the software continues to perform noticeably worse with every upgrade.

Yes, I'm rating this "Blocker", because the fact is that the trunk release of FileZilla is essentially broken. Major functionality no longer works as it used to, and there are serious problems that need to be resolved before this project can carry on with releases as normal. There is zero point in you guys releasing any more versions of this software ever again unless all of these issues are fixed, because apparently the releases from 2019 will work much better anyways. I think the project should do a test of all the software releases since 2019 to find out where exactly these kinds of things went off the rails, as those issues need to be resolved if FileZilla in its current form is ever going to be usable in the future again.

[Tim Kosse]

1 and 2 are actually symptoms of the same issue. We have recently released a fix for it in libfilezilla 0.38.1, to be included in the next release of FileZilla.

In the meantime you can try the latest nightly build.

Corrupted transfers. Quite frequently, on certain servers especially, file transfers get truncated at some multiple of 256 bytes, and I might have to retry the transfer 2, 3, 4, 5, 6, 7, 8 etc. times before the entire file actually fully copies. (FileZilla does correctly show the transfer "failed").

This very much sounds like a server-side issue with bugs in a particular server software. Which protocol are you using? Are it uploads or downloads? Which server software (product and version) is the running on the server machine?

[winzilla]

Ah, okay - well maybe I'll give it another try in that case, when there's a new release.

Note that the infinite loops (#2) only happened occasionally (a few times total) to me, whereas #1 happened constantly, dozens of times a day, every day. That was the biggest problem.

As for #3, it's with SFTP which is 99% of my FileZilla usage. I've only noticed the issue with uploads (from client to server), because that's mostly what I do, I pretty much never download.

So to answer the question, I presume it would be the OpenSSH server built into Debian. Doesn't happen all the time either, just occasionally, and usually if the problem happens once, it happens quite frequently that day on that server.

[Tim Kosse]

Strange, Debian is my preferred distribution and I'm uploading stuff with SFTP daily, never encountered any truncated files.

If you enable verbose logging on the debug page in the settings dialog of FileZilla and then connect to the server, you can see in the log which software it uses the next time you connect.

[winzilla]

All right, I took a chance and upgraded to 3.60.2.

It's not any better or worse. Issue #1 still happens constantly. I still need to close out the tab, cancel the stupid dialogs that come up, and restart completely over, every single dang time.

If FileZilla is incapable of keeping tabs open for long periods of time without corrupting it, then it should transparently start over with the same state as before, so the user doesn't have to do this manually. I'm still having to do this manually at *least* 15-20 times per day.

I might between 5-10 different tabs, and each time they become "stale", they all need to be completely reopened manually, including browsing to the same directories on both sides as before. Site connections (saved) make it a lot easier but that's not a workaround.

[winzilla]

Sorry to nag, but any update on this issue?
I've been upgrading more recently in the hopes this would be fixed, but it has not.

I haven't experienced the truncation issue in a while, that seemed to be random and only with certain client/server combos, so we can ignore that for now.

Issue #1 however is still very much a major issue. It has not gotten better *at all*. It still happens to me at least 50 times a day. It is no understatement to say that 10 minutes of my life, every day are wasted because of this bug, it is not a joke. In my opinion this should be priority #1 for fixing.

I'm happy to provide further debugs or help with testing in any way, I am really desperate. I have tried other SFTP clients because I really need to dump FileZilla at this point, it's absolutely destroying my productivity. Unfortunately, I can't find any that I like the user interface of as much... just so used to it at this point, I guess, that switching is hard :)

Anyways, if this could be revisited ASAP, that would be much appreciated. It does seem that this happens less with older versions. The hangs still occur, but older versions are able to "recover" and eventually reconnect, after maybe 10-15 seconds, whereas newer versions never reconnect and need to be force closed and reopened, EVERY SINGLE TIME.

We may as well remove the ability to keep tabs open at this point, they should just autoclose after a couple minutes of inactivity because they don't work ever again after that.

[Tim Kosse]

Cannot reproduce. Noticed one thing in your original report though:

Changing the timeout in settings from 20 to 0 has no effect.

If you disable timeouts, then yes, it will literally wait forever.

[winzilla]

Okay, so changing the timeout to 0 certainly made the problem even worse than it seems.

This exposes another problem. The minimum value for timeouts is 10. This is ridiculously high by itself. An acceptable value for me would be something like "2". If in 2 seconds, it hasn't been able to navigate to the new directory, it should just abort and immediately reconnect. There's no point in having to wait at least 10 seconds. It's such a huge waste of time.

Can you modify this to accept *any* value? The minimum should be 1, not 10. Users can then make their own decisions about this setting.

If this could be done, I'll test with a lower value and see if the responsiveness of the program improves with that change.

[winzilla]

I see there was a thread about this on the forum as well: ​https://forum.filezilla-project.org/viewtopic.php?t=48335

To be fair, I'm trying this mainly with a VPS, and that's where I seem to have the most issues - more so than with stuff on my LAN.

Buggy or not, it's not possible to account for all different providers and how they do things. I agree with the OP that this needs to be able to set to any arbitrary value.

I've manually waited 10 seconds a few times and it's able to reconnect at that point, so once this value is adjustable, this issue might be closable.

[winzilla]

I also tried setting <Setting name="Timeout">1</Setting> manually in the Settings XML file, and not opening the Settings dialog while FileZilla was open, but it doesn't seem to obey this value, even if set manually. So I guess a source change is really needed to make this possible.