what should we use to report bugs (the sourceforge bug tracker? it seems woefully inadequate)
~ Anders
FileZilla 3 development diary
Moderator: Project members
I'll hangaround, but can't promise anything because of heavy workload at Uni. Implementing surfaces (using B-splines) in OpenGL is next week's assignment and will probably take a lot of my time.botg wrote:That said, I could still use a few tracker moderators, I can't possibly handle every single tracker item by myself.
WOW i just installed the latest nightly build and i must say that it looks good 
but some things that got my attention right at the first start.
the icon theme.. why not use "Cyril" as the default theme? looks much better
another thing that i noticed was while i was playing a bit with the sizes of the display screens.. so the transfor screen, directory screen and the 6 (give or take a few) others. i think the moving of for example the transfer screen shouldn`t effect the size of the "local directory tree screen" but it should only effect the screen that`s above the one you are moving..
for the rest.. i would have expected to see new filezilla icons
specially since you are verry close to beta 1.. but it`s still the "old" icon..
and the total conclusion: GOOD JOB
i wish i could do c++ (gonna learn it soon) and help you with designing.. o well.. maybe in time.
but some things that got my attention right at the first start.
the icon theme.. why not use "Cyril" as the default theme? looks much better
another thing that i noticed was while i was playing a bit with the sizes of the display screens.. so the transfor screen, directory screen and the 6 (give or take a few) others. i think the moving of for example the transfer screen shouldn`t effect the size of the "local directory tree screen" but it should only effect the screen that`s above the one you are moving..
for the rest.. i would have expected to see new filezilla icons
specially since you are verry close to beta 1.. but it`s still the "old" icon..and the total conclusion: GOOD JOB
i wish i could do c++ (gonna learn it soon) and help you with designing.. o well.. maybe in time.Sidenode: filezilla-project.org is still offline, hosting company wants to exchange the hardware.
I've been trying to implement some automatic refresh for the remote directory listing after certain operations, for example file uploads.
However, I've noticed that the directory cache isn't coherent at all times if doing so.
Imagine the following execution order with engines A and B:
A: Initiate directory listing
B: Initiate file deletion
A: Already received parts of the listing, pending reply code
B: File deleted, update directory listing
A: Got reply, propagate new listing
Now we have the classical situation of a missed update in the directory cache. In order to fix it, directory listings have to be made exclusive, that is during a listing operation, no other engine is allowed to do any operation on the server that would invalidate the listing. In short, I need engine internal locking.
One example execution would look like this:
A: Initiate directory listing, lock out other engines
B: Initiate file deletion
B: Put on hold, pending listing
A: Already received parts of the listing, pending reply code
A: Got reply, propagate new listing
B: Resume deletion
B: File deleted, update directory listing
I've been trying to implement some automatic refresh for the remote directory listing after certain operations, for example file uploads.
However, I've noticed that the directory cache isn't coherent at all times if doing so.
Imagine the following execution order with engines A and B:
A: Initiate directory listing
B: Initiate file deletion
A: Already received parts of the listing, pending reply code
B: File deleted, update directory listing
A: Got reply, propagate new listing
Now we have the classical situation of a missed update in the directory cache. In order to fix it, directory listings have to be made exclusive, that is during a listing operation, no other engine is allowed to do any operation on the server that would invalidate the listing. In short, I need engine internal locking.
One example execution would look like this:
A: Initiate directory listing, lock out other engines
B: Initiate file deletion
B: Put on hold, pending listing
A: Already received parts of the listing, pending reply code
A: Got reply, propagate new listing
B: Resume deletion
B: File deleted, update directory listing
I think I'll add two new methods:
TryLockCache and UnlockCache.
TryLockCache checks if the cache is already locked by another engine on the same server and directory. If another engine has the lock, the function puts the calling thread into the lock queue and returns false. The caller is then responsible to suspend its work and to pass control. If the cache isn't locked, obtain the locks and return true, allowing the caller to continue.
UnlockCache frees the lock and then wakes up the first waiting engine from the queue by passing an event (direct wakeup by calling the waiting engine's processing function has the drawback of potentially causing a stack overflow).
For the List operation, the lock is obtained at the start of the operation and freed once the operation finishes. This ensures that listing operations are exclusive in its context (same server + directory).
All other operations which modify the cache obtain the lock before the actual modifcation and release it directly afterwards.
Due to the very nature of the locking mechanism, if the lock is already held, it's by another listing operation. Thus it might be possible to directly update the old cache, save the modifcation and after listing succeeds, replay the modifcation.
I will implement this stepwise by first implementing the lock only for the listing operations itself. Once that is in place, I'll analyze further ways to incorporate the locking into the other operations.
TryLockCache and UnlockCache.
TryLockCache checks if the cache is already locked by another engine on the same server and directory. If another engine has the lock, the function puts the calling thread into the lock queue and returns false. The caller is then responsible to suspend its work and to pass control. If the cache isn't locked, obtain the locks and return true, allowing the caller to continue.
UnlockCache frees the lock and then wakes up the first waiting engine from the queue by passing an event (direct wakeup by calling the waiting engine's processing function has the drawback of potentially causing a stack overflow).
For the List operation, the lock is obtained at the start of the operation and freed once the operation finishes. This ensures that listing operations are exclusive in its context (same server + directory).
All other operations which modify the cache obtain the lock before the actual modifcation and release it directly afterwards.
Due to the very nature of the locking mechanism, if the lock is already held, it's by another listing operation. Thus it might be possible to directly update the old cache, save the modifcation and after listing succeeds, replay the modifcation.
I will implement this stepwise by first implementing the lock only for the listing operations itself. Once that is in place, I'll analyze further ways to incorporate the locking into the other operations.
Partial locking has now been implemented. No longer should multiple engines try to to list the same directory at the same time.
In addition to that, I've rewritten the way directory listing notifications are handled. Previously, they did contain a copy of the listing. Even the engine-users not interested in these listings would always get a copy. On large listings, this did waste quite some CPU cycles.
Now the user of the engine has to explicitly request the listing from the cache if a notification about a new/updated listing arrives.
In addition to that, I've rewritten the way directory listing notifications are handled. Previously, they did contain a copy of the listing. Even the engine-users not interested in these listings would always get a copy. On large listings, this did waste quite some CPU cycles.
Now the user of the engine has to explicitly request the listing from the cache if a notification about a new/updated listing arrives.
-
TheAngryPenguin
- 226 Transfer OK
- Posts: 323
- Joined: 2004-03-08 18:40
As with the alpha builds, I'm getting the following error when starting FZ:
(click for full size...)
Also, drag and drop does not seem to work, and when renaming a file in the local pane, I have to refresh the view to see the new filename.
Finally, in either local or remote panes, typing the file/directory name (or the first few characters) does not move the selection to the file/directory.
(click for full size...)
Also, drag and drop does not seem to work, and when renaming a file in the local pane, I have to refresh the view to see the new filename.
Finally, in either local or remote panes, typing the file/directory name (or the first few characters) does not move the selection to the file/directory.
I've updated updatecheck.php, now users of older nightlies should get notified about the beta.
Until the final release, I'll mark all beta versions of FileZilla 3 as "release" and not as "beta" for the update wizard. That way, users can upgrade till final version without having to search manually with "Check for new beta versions" checked.
Until the final release, I'll mark all beta versions of FileZilla 3 as "release" and not as "beta" for the update wizard. That way, users can upgrade till final version without having to search manually with "Check for new beta versions" checked.
After much /poking, my wxTextCtrl enhancements for wxGTK got applied to wxWidgets CVS HEAD today, right in time for a 2.7.1 release of wxWidgets.
I'm also busy fixing lots of bugs found in beta 1. One particular issue caused the engine to become unresponsive after timeouts.
I plan to release beta 2 this weekend, even though that screws over my roadmap.
I'm also busy fixing lots of bugs found in beta 1. One particular issue caused the engine to become unresponsive after timeouts.
I plan to release beta 2 this weekend, even though that screws over my roadmap.
UNC paths bouncing here and there and everywhere,
lots of trouble that's beyond compare,
that's the problems I can't bear.
I'm fixing some problems with UNC paths found in the beta. And I absolutely hate the way Windows implements them. One typo in the servername and the application completely freezes.
lots of trouble that's beyond compare,
that's the problems I can't bear.
I'm fixing some problems with UNC paths found in the beta. And I absolutely hate the way Windows implements them. One typo in the servername and the application completely freezes.
Beta 2 is out fixing most reported bugs. Despite the ability to sort directory listings by modification date, there are no new features.
Users with automatic update checks enabled (the default), should get notified of the new version within less than 7 days.
So next weekend I expect the beta 2 download count to be higher than the beta 1 download count.
And of course the same for every other version released from there on. At least for FileZilla 3 this will hopefully prevent bugreports for truly ancient versions, like I get them for 2.x
Users with automatic update checks enabled (the default), should get notified of the new version within less than 7 days.
So next weekend I expect the beta 2 download count to be higher than the beta 1 download count.
And of course the same for every other version released from there on. At least for FileZilla 3 this will hopefully prevent bugreports for truly ancient versions, like I get them for 2.x
In preparation to adding TLS support, I've managed to compile GnuTLS. It has been a lot easier this time than ever before. I'm glad the developers of it are taking care of proper MinGW support.
Just libgcrypt was a little problematic, but -fkeep-inline-functions compilerflag did solve the problems.
In addition to that, I did fix a couple of problems in the engine, mostly SFTP or cache related.
One bug in particular was caused by PuTTY returning the wrong directory in it's canonify function. I did inform the upstream developers about it.
I've also committed a significant performance improvement for the transfer queue: Adding 50k files of zero size to the queue took several minutes. It's down to 5 seconds now. And I already have ideas for more speedups.
Just libgcrypt was a little problematic, but -fkeep-inline-functions compilerflag did solve the problems.
In addition to that, I did fix a couple of problems in the engine, mostly SFTP or cache related.
One bug in particular was caused by PuTTY returning the wrong directory in it's canonify function. I did inform the upstream developers about it.
I've also committed a significant performance improvement for the transfer queue: Adding 50k files of zero size to the queue took several minutes. It's down to 5 seconds now. And I already have ideas for more speedups.