Possible local panel non-update issue

I am not entirely sure if this is a bug, if its always been this way, or it is an intended behavior change, please close if this is not a bug. Obviously i wasn't sure how to title it either heh.

I have a queue with a number of folders in it to download locally from one site, half the queue was from one site and the other half from another site but marked failed (and several duplicate directories), but this specific setup is not neccersary to reproduce.

To reproduce, connect and queue several items (in my case on L side) for local download, make sure a number (in my case all) already exist in local explorer (as id downloaded them already before). Hit transfer to start the queue, both local side and remote side changed into the first directory in queue, since directory and files already existed i was then prompted for action. Hit skip all. Flashfxp correctly skips all files and moves on to second folder on remote side, however it does not change directory on the local side. What i mean is, it does seem to change local directory internally, as it does correctly notice the files already exist and skip them per my previous selection, however it does not update the local ftp view at all. It will go through all remote folders correctly noticing and skipping all files, but at not state does the local ftp view visually update to the current directory it looking at. Once the queue is finished, the local view then updates per usual returning to the location it was when the queue was started.

I dont recall it acting this way in previous versions (at least that i noticed), shouldnt it update the local ftp view as it goes in and checks each directory?

3.6 final, win2k, no idea if it matters but the 'allow local browsing during transfer' option is enabled... although since no attempt to do this during the operation is made it 'shouldnt' make a difference.

Actually we've optimized the local navigation so much that the changes are probably occurring too fast for you to notice, since all of the files are skipped automatically things really fly.

I did a test where a slowed things down and I can confirm that the local browser is changing folders.

An additional test I did was to skip each file one by one and that too allowed me to see the folder being changed.

I did some more tests quicker and slower and experience the same thing.

If i configure file exists rules to auto skip instead of waiting for the prompt, it updates the local ftp view and path bar correctly for each directory, we are talking about several hundred files in 50+ folders all done (skipped) in under 4 seconds.

If it correctly updates under these circumstances then i dont think the speed has anything to do with this issue, since when i originally noticed this it was under much slower circumstances.

From what i can tell, this unusual behavior only occurs when FlashFXP prompts for action, whichever folder it is in when the prompt appears AND skip all is selected gets visually stuck, no ftp view or pathbar updates are performed until the queue is finished. Unless there is a file that was not there before (since this modifies the contents). Note that resume all and overwrite all also function correctly.

For the sake of thoroughness i checked the tree view as well, this also fails to update after a 'confirm file replace' prompt.

I am not sure what other info i can provide to help reproduce this, but it is definately happening.

I stand corrected, After taking a bit more time reviewing the source code and comparing skip all vs skip there is a difference. My eyes must of been playing tricks on me last night.

FlashFXP doesn't change folders if all files within the folder are skipped with a skip all, one file must be transferred in order for the folder to change.

This is done for performance and speed, While FlashFXP could change folders its just an unnecessary task for it to do when the files are being skipped.

I see, is there a reason that this behavior is not the same if all files are being skipped per file exists rules vs all files being skipped per prompted selection?

Personally i would prefer it to update and be concistant, but to each there own and its definately not something of particular importance either way, just seems odd and inconcistant and had never noticed it before.

If skipall is in effect and the local file exists we already know the outcome, rather than continuing a long and lengthly procedure of events (including changing folders) we skip all of that and go to the next file.

This wasn't changed in v3.6 and this behavior can be found in 3.4 as well.