Strange interface/behavioral issues possibly related to caching and/or compare folder content

Ok, will do my best to explain this as fully as possible.

Win2k pro sp4, 3.6 final.
Global caching option set to off

Try this...
Connect to two remote sites where one (or both) have the 'cache directories' setting configured to intermediate (greyed box as to abide by global config).
Use compare folder contents (spefics of this feature not important) to highlight some files for transfer, drag them to other side to queue and autostart the transfer (text files will do for testing purposes).

NOTE: the SOURCE site should be the site with cache directories configured to use global setting. I was unable to reproduce these issues with any source site where cache directories settings for the site was specifically set to either on or off.

Result is an interface bug that prevents the toolbar buttons for that side of program (toolbar relating to source site) from working at all, refresh button does nothing, compare folder button seems to work still, d/c and stop buttons etc also fail to function.

A little more testing showed that buttons also become mute during the transfer (after following same above steps), meaning that stop and d/c etc do nothing.

Issues do not seem to occur if site specific caching option is configured, not set to use global configuration.
Issues do not seem to occur if 'compare folder content' was not performed in order to select the files to transfer, manually dragging files works fine without causing the strange behavior.

NOTE: It seems to only be related to the toolbar itself, refreshing with kb shortcut or right click menu functions correctly, and entering raw commands to ABOR or QUIT works also, but the toolbar buttons do not.


I also noticed some other unusual behaviors that seem to only occur after compar folder content is used. While doing some tests for the above issues, as well as testing for the previously discarded compare folder content bug just reported a couple of things acted strangely.

Firstly, when comparing folder content, adding content to queue (not dragging to auto start transfer), then right clicking in queue window and selecting transfer, the source folder is not refreshed prior to starting transfer as it should be (accoding to preferences).

Secondly, after noticing this the 'switch view' toolbar button on the local side seemed to break, it changed the state of the button, and changed the contents of the ftp view area, but the toolbar went blank (should have loaded/shown the remote toolbar buttons). Once i d/c the other side and switched back and forth (on that other side) between local/remote the left side (formerly malfunctioning) seemed to fix itself (not update, but the bottuns functionality returned to its correct state, switching between loca/remote worked correctly again).


I would have to guess that there is some kind of interface bug/problem causing these weird behaviors, that is quite possibly related to Compare Folder Content feature and/or Directory Caching options. It also seems to be related to the other bug report regarding compar folder content and refreshing local side.


It seems strange that i and others have never noticed this before during beta testing. It may be worth noting that in previous beta testing i had two seperate installations of flashfxp, one being the 3.4 final for reliable use and the beta installation for testing and use when around to keep an eye on things (cant use a beta for important stuff when not around to keep an eye on it). While now i have upgraded my main installation from 3.4 final to 3.6 final. (no testing has been done on a fresh install since its not possible to install same version a second time on same pc)


IMPORTANT EDIT: After posting this i almost immediately noticed that you dont actually need to transfer any files (after comparing folder content) in order for this to occur, i compared remote L to local R when i knew content would be the same, the buttons on the remote L side immediately become mute.

FWIW, if I set Cache Directories to true or false (instead of inherit) in Site Manager, it doesn't alter the button behaviour. Whichever side's Compare Folder Content button you use, that side's Refresh toolbar button is killed. Seems to be a separate issue.

Even stranger still.. in my tests it only seemed to happen when caching was configured to inherit. In your tests is it just the refresh button that stops working or does the entire toolbar become mute.

Originally Posted by DayCuts

Even stranger still.. in my tests it only seemed to happen when caching was configured to inherit. In your tests is it just the refresh button that stops working or does the entire toolbar become mute.

Wow, the whole toolbar does stop working.

Here's something -- if I right-click either toolbar and select to show or hide a button, both toolbars begin working OK. The mute toolbar returns to life, and Refresh button on the other one starts working again.

Indeed, i had noticed that also, i assume adding/removing buttons trigger a toolbar reload that clearly fixes whatever the problem was.

I'm not sure if I'm doing it wrong or what, I'm fairly certain I'm doing exactly what you outlined above but for whatever reason I'm unable to reproduce this behavior on Windows XP.

This occurs for me on win2k pro corp w/ sp4, i do not have an xp system or vm to test on at this time. Could this be something introduced by Vista optimizations that may not work correctly under win2k?

Simplest way to reproduce is to just connect to the same site twice, hit compare button on whatever side you desire, then try to click the refresh button on that same side. For me (and i guess the other guy posting about it) the refresh fails to do anything, as do most of the other buttons. I believe the compare button actually still functions correctly oddly enough, but otherwise the rest of the toolbar is stuck and useless (even the button to switch between local and remote views) until you force the toolbar to reload but adding/removing buttons.

We'll we've got a bit of a problem. I managed to reproduce the problem on Win2k and then I started trying older builds until I found one that wasn't bugged. I had to go all the way back to July 2007 build 1184.. So I loaded up my trusty svn client and started browsing our software repository and then I start freaking out....

One of the folders within the svn repository is empty and its not keeping track of the changes within it.

My local backups only go back to august 2007, everything else is archived to dvd and stored in a remote location.

With no obvious explanation to this oddity appearing on win2k I am at a loss. With so much time passing between then and now it's going to be very difficult to identify the exact change that did it.

This is going to take up a lot of time to resolve.

I have no idea how many of us nutters are still using Win2k, but don't feel any need to go to this much trouble on my behalf; I'll cope with the bug. (I should really be using XP anyway, but my PC maxes out at 512 MB RAM and XP is too fat

You might still want to get that SVN looked into though

I immediately added the current revision of the missing files to the repository, the files that were accidentally excluded aren't changed very often. Though after spending a few more hours researching this issue last night I have pretty much ruled out any of the changes made in those files as possible conflicts. I wont know for sure until I pick up my dvd archives later today.

It is a rather minor bug but it's also one that should of been caught much sooner than this,
I'm really shocked that no one had discovered it sooner.

It is definately unfortunate that it wasn't, unfortunately due to my dependance on the program i tend to leave my stable install alone and test betas on a seperate install that i only use under less important circumstances and never let run while i am not around. So i guess i am not the best candidate for beta testing in that respect. It is a shame i didnt use the betas a bit more, as this is something noticed very quickly once i updated my stable install.

Luckily this is not an issue that is damaging to the functionality of the program, tedious as it may be to add/del buttons to fix the toolbar, it shouldnt affect the day to day use.


Telcontar: Heh, i guess win2k is rather old and even officially unsupported by ms now, but i still prefer it to XP regardless of resources. But then i can be a little habitual and part of the reason for keeping my main system on win2k is the complete lack of neccersity to change. Everything i use works fine on win2k and i think i've had one issue with it in about 5 years since my last planned format/reinstall. (damn power surge corrupted system disk late last year, and had left some hardware less stable also)

I spent most of the day going reviewing old source and I think I'm finally getting close to figuring something out, I'll probably have it figured out tomorrow.

One thing I am for sure about is that the vista fixes did break it, I'm just not sure which one did it.

This issue has been resolved for the next release.

The bug was introduced by some code added for windows Vista when building the toolbar, While the same code works fine on XP, apparently Windows 2000 doesn't like it.

Whee =)

<Extra characters to bypass minimum message length>