FileZilla 3 development diary
Moderator: Project members
For that I'll need code to verify signatures and such. For the first betas, there will be no signature checking.Trou wrote:will you sign the updates and automatically check the sig ? because if someone takes over your update server, he could deploy a malware easily.
But from the final release ongoing, everything will be signed. After implementing SSL/TLS support in FZ3, the neccessary functions for X.509 certificates, signatures and such should be available.
The client side code is complete now. FileZilla is now able to automatically check for updates. This feature is enabled by default and will check every 7 days. Of course this can be controlled in the settings dialog.
Now what's missing is the actual script behind it running on my server, as FileZilla has to get the version information from somewhere.
But that's not "that" importent. Theoretically it would suffice to create that script at the release of the second beta.
Like I've mentioned earlier, I'll next work on the file exists dialog which is only partially implemented.
A final thing will be to cut down on the debug spam in the message log, it severly slows down operations.
After that, I think the first beta of FileZilla 3 will be ready. Bringing me nothing but work. Bugs, bugs and more bugs
Now what's missing is the actual script behind it running on my server, as FileZilla has to get the version information from somewhere.
But that's not "that" importent. Theoretically it would suffice to create that script at the release of the second beta.
Like I've mentioned earlier, I'll next work on the file exists dialog which is only partially implemented.
A final thing will be to cut down on the debug spam in the message log, it severly slows down operations.
After that, I think the first beta of FileZilla 3 will be ready. Bringing me nothing but work. Bugs, bugs and more bugs
I'm currently trying to improve performance of FileZilla, especially when transferring many small files, it uses way too many CPU resources.
So far I could identify the message log as major CPU hog, at least under Windows.
While profiling, I have been able to identify a few flaws in the text control class wxWidgets itself which lead to decreased performance. Nothing major, but everything counts.
Also, the directory listing parser constructor uses a lot of cpu resources, over 1% in total! during the profile runs. This is due to the month name map, constructing it is CPU intensive (whereas lookups are very quick). It gets constructed every single time a directory gets listed. I'll change it so it will only get constructed once.
Next issue is the queue: The progress lines are child windows, constructing and destroying them is CPU intensive. I'll update the code to use a pool of status windows and will just hide them if unused.
Overall, this should result in increased performance. As at the moment, FileZilla 2 still performs faster than FileZilla 3. And I want FZ3 to be at lesat equally good. Not an easy task though, due to the extra layers of GUI library code needed for cross-platform development.
So far I could identify the message log as major CPU hog, at least under Windows.
While profiling, I have been able to identify a few flaws in the text control class wxWidgets itself which lead to decreased performance. Nothing major, but everything counts.
Also, the directory listing parser constructor uses a lot of cpu resources, over 1% in total! during the profile runs. This is due to the month name map, constructing it is CPU intensive (whereas lookups are very quick). It gets constructed every single time a directory gets listed. I'll change it so it will only get constructed once.
Next issue is the queue: The progress lines are child windows, constructing and destroying them is CPU intensive. I'll update the code to use a pool of status windows and will just hide them if unused.
Overall, this should result in increased performance. As at the moment, FileZilla 2 still performs faster than FileZilla 3. And I want FZ3 to be at lesat equally good. Not an easy task though, due to the extra layers of GUI library code needed for cross-platform development.
I've been getting this error more and more often with the filezilla 3x nightlies:
I think there may be something wrong with whatever is packaging filezilla nightlies.
Some weeks I've seen this twice in a week, just got another one today. Usually never see it in the past, but then started seeing it more and more often, same error.
This error makes that nightly unuseable.
bzip2: Version 1.0.3, 15-Feb-2005
debian sid, latest packages.
<update>I changed my FileZilla Nightly Installer script to test for this CRC error, and to halt installation before it removes your current working filezilla. So that will take care of the problem for me until that gets resolved on the server.
Code: Select all
bzip2: Data integrity error when decompressing.
Input file = (stdin), output file = (stdout)
It is possible that the compressed file(s) have become corrupted.
You can use the -tvv option to test integrity of such files.
You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
Some weeks I've seen this twice in a week, just got another one today. Usually never see it in the past, but then started seeing it more and more often, same error.
This error makes that nightly unuseable.
bzip2: Version 1.0.3, 15-Feb-2005
debian sid, latest packages.
<update>I changed my FileZilla Nightly Installer script to test for this CRC error, and to halt installation before it removes your current working filezilla. So that will take care of the problem for me until that gets resolved on the server.
Happened again today. Anyway, at least I'm not deleting my working install before installing the new one anymore, the bzip2 -tvv FileZilla3.tar.bz2 test works fine, I just automated in my script so it has to pass that test successfully before going on with the (re)install.
Seems to be happening more the last month or two though.
I had to go back to thursday's build to find one without these eof errors.
Seems to be happening more the last month or two though.
I had to go back to thursday's build to find one without these eof errors.
If you're a developer, a constant stream of heavy bricks will be thrown at you. Some of the clinker comes from the used libraries. Now while all libraries' masonry flies dangerously around, I got hit by a wxBrick again.
This time it's about radiobutton groups. Basically a radiobutton group are consists of all the mutual exclusive radiobuttons. In other words, if you click one raidobutton and another one gets deselected, they belong into the same group.
During radiobutton creation, you tell wxWidgets which buttons mark the start of a new group by using the wxRB_GROUP style. Under Windows, wxRB_GROUP will get translated into BS_GROUP which is recognized by the underlying native control.
However, I want to change this style at runtime: Depending of the context in which my dialog will be used, some radio buttons should be hidden. Unfortunately under Windows, if I add the wxRB_GROUP style later, BS_GROUP doesn't get passed to the native control.
So I had to write a patch which adds the desired behaviour. Details can be found here: http://sourceforge.net/tracker/index.ph ... tid=309863
This time it's about radiobutton groups. Basically a radiobutton group are consists of all the mutual exclusive radiobuttons. In other words, if you click one raidobutton and another one gets deselected, they belong into the same group.
During radiobutton creation, you tell wxWidgets which buttons mark the start of a new group by using the wxRB_GROUP style. Under Windows, wxRB_GROUP will get translated into BS_GROUP which is recognized by the underlying native control.
However, I want to change this style at runtime: Depending of the context in which my dialog will be used, some radio buttons should be hidden. Unfortunately under Windows, if I add the wxRB_GROUP style later, BS_GROUP doesn't get passed to the native control.
So I had to write a patch which adds the desired behaviour. Details can be found here: http://sourceforge.net/tracker/index.ph ... tid=309863
fzsftp on mac
Aloha,
I was wondering what I need to do to get the nightly running on a mac. Everything works well except when trying to connect via sftp. I get the "fzsftp could not be started" message.
I was wondering what I need to do to get the nightly running on a mac. Everything works well except when trying to connect via sftp. I get the "fzsftp could not be started" message.
I've moved the network configuration tester to port 21 on my server, and promptly triggered a big problem.
The Windows Firewall from microsoft itself sabotages my FTP traffic by maliciously modifying the PORT command.
I can only give one advice: DO NOT use Windows Firewall, it is broken by design. What the windows firewall does is nothing else than data sabotage.
The problem is simple: What gives the windows firewall the right to assume that the used protocol is FTP and mangle it at will?
It could be a different protocol or a newer revision of FTP with a different meaning of some commands.
Unless ordered to so so by the user itself, a firewall should never ever modify any data.
Fortunately the network configuration wizard of FileZilla 3 helps to catch these misbehaving firewalls. However, should users be unwilling to disable them, I might be forced to deny them any support for FileZilla unless they disable all firewalls. This would be easy to check, as they would need present me a cookie from the network configuration wizard they'll only get if it succeeds. This is a drastic measure I really don't want to implement.
The Windows Firewall from microsoft itself sabotages my FTP traffic by maliciously modifying the PORT command.
I can only give one advice: DO NOT use Windows Firewall, it is broken by design. What the windows firewall does is nothing else than data sabotage.
The problem is simple: What gives the windows firewall the right to assume that the used protocol is FTP and mangle it at will?
It could be a different protocol or a newer revision of FTP with a different meaning of some commands.
Unless ordered to so so by the user itself, a firewall should never ever modify any data.
Fortunately the network configuration wizard of FileZilla 3 helps to catch these misbehaving firewalls. However, should users be unwilling to disable them, I might be forced to deny them any support for FileZilla unless they disable all firewalls. This would be easy to check, as they would need present me a cookie from the network configuration wizard they'll only get if it succeeds. This is a drastic measure I really don't want to implement.
-
Fenix*NBK*
- 500 Syntax error
- Posts: 13
- Joined: 2004-06-14 05:59
- Location: Netanya, Israel
Hi all !
I am sorry - but I really dont have the time to read all the 1000 of posts here.
I am interested in status of FileZilla 3 for Linux.
Does it runs? Stable? Would you recommend me to run it on Linux in it's current state for production work?
Currently I use KDE Konqueror on Linux, and Filezilla 2 on Windows.
I am sorry - but I really dont have the time to read all the 1000 of posts here.
I am interested in status of FileZilla 3 for Linux.
Does it runs? Stable? Would you recommend me to run it on Linux in it's current state for production work?
Currently I use KDE Konqueror on Linux, and Filezilla 2 on Windows.
I got some good and some bad news.
First the bad news. Please have a look at the following log snipped from FZ3 while trying to delete some files over an SFTP connection:
One can easily see, that the third command gets sent before the reply to the second command.at some point, multiple commands get executed, before their reply got sent. This definitely is not supposed to happen. Time to debug a little.
Now the good news: I'm putting together all the bits and pieces for the file exists dialog, most of the "Always use this action" functionality has been implemented.
First the bad news. Please have a look at the following log snipped from FZ3 while trying to delete some files over an SFTP connection:
Code: Select all
Command: rm /home/codesquid/test/asyncrequestqueue.cpp
Response: rm /home/codesquid/test/asyncrequestqueue.cpp: OK
Command: rm /home/codesquid/test/asyncrequestqueue.h
Command: rm /home/codesquid/test/buildinfo.cpp
Response: rm /home/codesquid/test/asyncrequestqueue.h: OK
Command: rm /home/codesquid/test/buildinfo.h
Response: rm /home/codesquid/test/buildinfo.cpp: OK
Response: rm /home/codesquid/test/buildinfo.h: OKNow the good news: I'm putting together all the bits and pieces for the file exists dialog, most of the "Always use this action" functionality has been implemented.