FileZilla 3 development diary

[botg]

Not testworthy yet, still too many rough edges

Fully aware that it doesn't compile yet, didn't install the required dependencies yet on the build slaves.

[botg]

I've updated this server to Debian Squeeze which does have a recent enough SQLite3 version. I'll now update the build environments one-by-one so that you can test the nightlies. Please don't report problems, I already know too many things not yet working again

[botg]

More work than I thought. Since dash is not the default shell as opposed to bash, I spent a lot of time getting all those bashisms out of the build scripts.

Other than that I've been working on the configure script. Some compilers need -std=c++0x to enable unordered_map, others don't support it. On some platforms, unordered_map resides in the tr1/ subdirectory. I've added the necessary checks to configure.

[botg]

Made another nice improvement to the queue storage. This time, instead of storing local and remote paths directly, they are stored in separate tables and only an index into that other table is stored. Keeps database sizes small and further speeds up loading and saving.

Unfortunately nightly users need to delete their database. But you were warned when running the nightly

[boco]

2011-05-01 builds failed.

What I don't like about the database is that it will not decrease in size again. Having a big useless database file forever just because I used a big queue once is not desirable.

[botg]

Just a matter of calling VACUUM;

[boco]

Just a quick question. As SQLite is a lot faster, wouldn't it now possible to have a regular ''queue snapshot'' at runtime? So if FileZilla crashes, it can be recovered?

[botg]

Yes, but only if limiting FileZilla to be started only once at the same time.

[boco]

What if the queue file name would include the PID (process ID) of the FileZilla instance? Then you'd have one queue per running instance of FileZilla. I guess all OS have something like PID.

[botg]

Two systems sharing the same storage location on some network share can use the same process identifier. PID files are inherently dangerous, I strongly recommend not using them. Since there is no atomic way to operate on PIDs and since PIDs can be reused, their use will and does cause problems. Example how some programs kill a daemon: Open PID file, read PID, kill PID. If inbetween these steps the daemon dies and another program gets assigned the same PID, an innocent program gets killed.

Theoretically it is possible to solve this problem using other means, but requires a lot of work to be safe in all situations. Distributed concurrency is hard to get right.

[botg]

After careful consideration, I have not come up with a viable solution that would catch all corner cases.

[stealandmodify]

so is it yet possible in FileZilla 3.5.3 to commandline connect to a site from site manager and upload a file to it?
I have searched everywhere for this simple thing and seems it cant even do it!

[botg]

No, it isn't. For automated tasks, you might want to consider a dedicated command-line client.

[kadushkin]

Is it possible to implement the ability to assign appropriate ways FTP & URL aliases?
For example: the path on the FTP /domains/mysite = URL http://mysite. com
These settings are set and stored for each FTP.
And later in the command in the context menu (like "Copy URL to clipboard") to get the name of a file or folder on the http server.

Options & settings:


How to use:

[botg]

It's possible. Patches welcome.