FileZilla 3 development diary

[botg]

Yesterday, somebody submitted a bug report in the Ubuntu bug trackers regarding a theming issue visible in FileZilla. See the attached screenshot at https://bugs.launchpad.net/ubuntu/+sour ... bug/284755.

By chance I also had a working Ubuntu 8.10 beta installation, so I could test it myself. Took me a while to figure out that the "new human" theme is in fact called "DarkRoom", yet still is contained in the human-theme package. This needs to be fixed by the Ubuntu devs/packagers.

With the theme set, I was able to reproduce the original issue. Quick look at the source of wxWidgets and shortly after I had a working patch, see http://trac.wxwidgets.org/ticket/10089.


On related notes, I did a small change to the message log, it'll now use brighter colors if the text control background is dark. While it doesn't have any effect if using the DarkRoom theme, it's quite useful if using the somewhat similar DarkLooks theme. Actually it helps on all platforms and all themes with dark text control backgrounds.

[botg]

Every time I release a new version of FileZilla, I am getting complaints.

1. "Again an update, I'm sick of updating every day, week, month, year, whatever, you need to make less releases
   • If I had the time, I'd do new releases even more frequently. Unfortunately creating a release is time consuming.
   • Did I ever force you to install every single update? Can't you just click on Cancel on the upgrade availability notification? You know, it doesn't come back. Did you ever look into the settings dialog? You can change the checking interval and even completely disable the update checks.
   • Even if you do not want the frequent updates because you do not have any problems with the previous versions, there are many more users which do want the new features and fixes in the new version.
2. "The update is huge, I do not want to download all of FileZilla again, can't you do incremental updates?
   • Unless you're one of the 10 people worldwide still using 56k modems, you have enough bandwidth to download FileZilla in just a few seconds.
   • Creating incremental updates adds a huge amount of complexity to the release process and is very prone to errors. I just don't have the time to waste time on it
   • Combined with the previous complaint, incremental updates are impossible. What if user skips a couple of updates? Do deltas against all previous versions? That would be madness and would take days to generate all the deltas. The alternative is to fall back to downloading the full file again. So nothing gained at all by incremental updates.

Perhaps I should implement a killswitch to force users to update once every week.

Code: Select all

3.1.5.3.2.2.6.2.6.7.3.1 (2008-10-28)

! You have to update because I say so. Now dance, monkeys!
+ More annoyance
+ Even bigger setup file
- Fixed nothing
- Blood pressure rising

[da chicken]

In general, I believe in "Release early. Release often."

I this case I find the updates to FZ can be a bit irritating because the SourceForge site tends to pass me off to a few mirrors that are slower than molasses in January. The CPU spikes, and the application hangs.

I don't think it's a bug in FZ. I think it's a bug in Microsoft's C library. It's still irritating.



(Note that the figure of 92.75 there is CPU utilization.)

[botg]

da chicken, which version did that happen with?

[da chicken]

That was during the last update from 3.1.4.1 to 3.1.5.

It did the same thing during 3.1.3 --> 3.1.3.1 and 3.1.3.1 --> 3.1.4, but 3.1.4 --> 3.1.4.1 went seamlessly. The fix is to terminate the process and try again. That works about 80% of the time, but sometimes I just get fed up and download the setup directly. That's what I did with 3.1.5.

I don't have the debugging symbols installed so I've no idea what's at msvcrt.dll!endthreadex+0x3a or what ntkrnlpa.exe!KiUnexpectedInterrupt+0x7d is. Then again, I'm not fully sure of the nomenclature here, but I'm assuming it's the offset of the actual function being executed. But I'm not a developer.

[boco]

Just wanted to chime in and confirm that it also happened to me. Seems to be Sourceforge assigning a mirror located on Mars or beyond...
Shouldn't this assign a server near to me?

[botg]

One of the reasons why manual downloads have moved to ohloh. The auto-updates might follow in the future.

While I have often seen transfers timing out with the SF.net mirrors, I did never observe things like increased CPU usage or freezes.

[boco]

It freezes, but if you wait and let the connection timeout, it continues. So the hanging connection seems to block the rest?

[da chicken]

Yeah, but it takes a long time to time out. 5 minutes easy.

[botg]

See the settings dialog, there's your timeout value.

[da chicken]

Huh? What does the FTP transfer timeout have to do with this weird referrer bug? Mine's set at the default of 15 seconds and the application clearly hangs a lot longer than that. At the very least, it hangs long enough for me to:

1. Realize it's hung.
2. Go Start --> Run --> "procexp"
3. Find FileZilla in the process list.
4. Open the properties dialog for the process.
5. Identify the hung thread.
6. Open the stack for the hung thread.
7. Take a screenshot.

It's minutes.

[botg]

Are you using any firewalls, virus scanners or so-called security solutions?

What happens if you completely uninstall them?

[da chicken]

No on-access AV scanner on this PC and Windows firewall is disabled. I do have Spybot Search & Destroy, but that's also not running its real-time component.

I have a Linksys WRT54GL running the latest DD-WRT firmware, but the SPI firewall on that is disabled. FTP ports are forwarded (port 21, 50000-51000) but that's got nothing to do with the updater which is an http session AFAICT. Leastwise, the updater claims to be using an http URI.

It's not repeatable consistently. I'm willing to blame SF.net's shitty mirror selector just on that alone.

[botg]

Let's talk about session-management under Linux, *BSD and others (but neither MSW nor OSX).

Every time when you log out of Gnome, KDE, Xfce or whatever desktop environment you use (aka ending the session), one thing happens: All running programs get closed. The interesting part is how they get closed. At least under Gnome and KDE, it seems the X server gets shut down and all programs using it just die. (I leave figuring out the exact details as an exercise for the interested reader)

Such behavior is a bad thing for FileZilla since FZ only saves its queue if closing the program gracefully. This is done for performance reasons since it can take quite a while to save several hundreds of thousands of queue items. Ending your desktop session while FileZilla is running makes you loose your queue. Not a nice thing to do.


I've noticed however that not all programs get treated like this, some will get a fair chance to close themselves before the session ends. Historically, this was done with libraries specific to the used desktop environment. I don't know these libraries and don't want to know them, too much effort.

Recent Gnome versions however have a simple D-Bus interface for its session manager. Under the org.gnome.SessionManager interface, programs can register to receive QueryEndSession and EndSession D-Bus signals to which they have to respond.

Remark: Finding information about session management is hard. You need a degree in Advanced Google Usage to find the information you want. Forget about other search engines entirely.

The available API documentation (http://live.gnome.org/SessionManagement/GnomeSession and http://www.gnome.org/~mccann/gnome-sess ... ssion.html) didn't seem too complex so I decided to implement support for it.

From now on it was easy. A search instantly brought up a libdbus wrapper for wxWidgets: http://symmetrica.net/wxdbus/

A few minor fixes to get it compiled, adding a few missing functions and a couple of hours later I had a working prototype. Ending the session gracefully closed down FileZilla with the queue saved to disk.


To my surprise, it failed when I had multiple instances of FileZilla running. My own code looked sane (as sane as a prototype can get) and the dbus-monitor tool clearly showed that it had to be some deeper problem.
Once again, this shows the beauty of free open source software. Since Gnome is open source, I could look at the source of gnome-session and analyze what's going on. In addition, it is free software, so I could also write an experimental patch.
As for the details of this bug, please read http://bugzilla.gnome.org/show_bug.cgi?id=559469, I do not want to repeat myself too many times.

With the patched gnome-session, everything works perfectly now. Regardless which task I'm doing in FileZilla at the moment the session ends, the queue and settings all get saved.

[da chicken]

BUT THEN I CAN'T USE VENDOR LOCK IN I HAVE TO PRODUCE A BETTER PRODUCT OR NOBODY WILL BUY A SERVICE AGREEMENT