FileZilla 3 development diary

[botg]

I have no idea. Could have been a flipped bit as well

[botg]

Good news everybody. The socket class is now complete. FTP(S) has been completely ported to use the new class, only thing missing is the http class (as used by the update check code) and the network configuration wizard.
Once that has been completed I can release a first beta.

Future improvement: Move file transfers entirely into secondary threads using OS-specific optimizations, e.g. IO-completion ports (MSW), splice (Linux) and similar zero-copy features.

But before I'll implement that, the new class needs to be thoroughly tested, otherwise the gap would get too huge.

[boco]

So that will mark 3.0.11.1 the last working release for Win2000?

[botg]

Yes. Unless somebody writes a patch that passes my unwritten quality expectations.

[botg]

Ripoff: http://www.smartftp.com/features/visualcompare.php

At least they are trying

[botg]

/me shuffles to the drawer to fetch some SOCKS.

[boco]

/me shuffles to the drawer to fetch some SOCKS.

LOL nice one.

/me goes over to my desktop to open windows.

[botg]

I've finished implementing SOCKS5 and HTTP/1.1 proxy support. Unfortunately SF.net is broken again, cannot commit changes to the repository anymore.

I'm getting very frustrated with SF.net, I think I need to migrate the services soon to my own server.

[botg]

A few days ago, some user reported a bug in which FileZilla was unable to resume a download of a 7 GiB large file. The server was large file aware and did support resume of files > 4GiB. Yet FileZilla thought the server did not support this.

FileZilla does have a heuristic to detect servers not supporting resume of such large files (which there are plenty). It issues the REST command with the remote file size - 1 as argument and downloads the file. If REST fails or if the server does not transfer exactly 1 byte, the server does not support resume of large files.

So far so good, but for some reason, FileZilla didn't send something like REST 7GiB-1, but used an offset around 12 GiB. I had a hunch and compared the hexadecimal representation of both sizes. Low 32bits were identical, but the high 32 bits of the 64bit integer were doubled.

I wondered why this problem never showed up in my testing, but then I remembered that the user had a 64bit version of FileZilla. Trying it myself on a 64bit installation of Fedora, I could reproduce the problem. Checking my code, I could not found any flaws, so I checked wxWidgets' code.

As it turned out, on 64bit Linux, sizeof(unsigned long) == 8
The class in wxWidgets that handles 64bit integers is called wxLongLong and the function to get the low 32bits looked like this:

Code: Select all

unsigned long GetLo() { return (unsigned long)m_ll; }

That worked fine on 32bit systems, but on some 64bit systems (those with 8 byte long), it returned the 64bit integer unchanged.

The effects on FileZilla were the following on large files:
- Failing resume capability tests
- Transfer progress incorrect
- Uploads could not be resumed properly
- Overwrite if different size file exists action almost always reporting different size
- possibly more

While the effects on FileZilla were rather harmless, other programs might not be as fortunate. Programs using the output of GetLo() to allocate memory, address memory offsets or similar would be in all sorts of trouble.
If you're the wxWidgets package maintainer of a Linux distribution, you shoud consider backporting this change: http://svn.wxwidgets.org/viewvc/wx/wxWi ... hrev=54663 (If you're worried about ABI, you can just replace the unsigned long with wxUInt32 inside the GetLo() function.)

[botg]

I like databases, they make my life manageable. In particular the versioninfo database with the newly added compat table. I wish I had that back at version 3.0.7 of FileZilla when I could no longer distribute binaries for OS X 10.4

As I wrote before, Windows 2000 support will be dropped with 3.1.0 (unless somebody else writes a patch). See what the update check page returns if called from Windows 2000 (NT 5.0) and Windows XP (NT 5.1):
http://update.filezilla-project.org/upd ... ersion=5.0
http://update.filezilla-project.org/upd ... ersion=5.1

[botg]

Once again, I got one of those hillarious mails where some stupid user complains about things he doesn't even understand:

Wieso versuchst du auf imstupid83.kicks-ass.net zuzugreifen.
Ohne passwort wird das nichts. Ich bitte dies zu unterlassen. Danke

And the translation:

Why are you trying to access imstupid83.kicks-ass.net?
Without password you won't succeed. Please refrain from doing this. Thanks

For brand awareness, the server prints my e-mail address in its welcome message. And user is too stupid to distinguish between the server reply and the client that's connection. I pray to you Jebus, let it rain brain! (Yes I do believe in Jebus. There has to be somebody to do all the meaningless tasks the FSM won't touch with his noodly appendage)

[botg]

Some ideas for 3.1.1:

- Don't require a username for ask and interactive logon types
- A new event dispatcher for the networking classes, current one are getting too complex
- See if it is possible to not blank remote file list if getting disconnected on behalf of the server.

[boco]

- See if it is possible to not blank remote file list if getting disconnected on behalf of the server.

Just dim it (change the font color to grey'ish maybe) so you see the disconnection.

[botg]

Of the three things I've mentioned in my previous post, only the first one will be in 3.1.1. I've spent quite some time on the event dispatcher, but had to discard it eventually. My prototype didn't work at all. I'll probably try again in a future version.

[boco]

Take your time, it's a leisure time project after all.