Remote view disconnects during large transfers

[mrsmiley18]

When uploading a large amount of files (about 5Mb
spread across several thousand files), after about 10
to 15 minutes into the transfer, the remote server
views (tree and file listing) go blank, and the remote
file window says "Not connected to any server".

Even the toolbar icons are highlighted/disabled as if
I am no longer connected to the remote server.

Yet even though the GUI is in this state, the program
is still transferring all the rest of the files in the
queue, I just cant see the remote view being updated
any more.

[mrsmiley18]

Screenshot

[Tim Kosse]

FileZilla uses secondary connections to handle transfers,
the primary connection only gets used to browse the server.
Most servers disconnect users which are idle for a while.

[mrsmiley18]

Please re-read what I wrote and compare to the screenshot - "the program is still
transferring all the rest of the files in the queue". I'm not actually disconnected, the
FZ server views indicate I am though.

The reason I logged this is because the server wasn't idle. I was in the middle of
transferring a few thousand small files, yet the GUI said I was disconnected about 15
minutes into the transfer even though files were still transferring in the background to
the server.

In case I'm not being clear enough, the remote view (both tree and file list) of the
server says disconnected, but the queue and message log views still work fine and
transfer the rest of the queue contents.

I had about 1500 files queued up that in total equalled 5MB. Each file on average was
only a few KB as they were all PHP scripts and small images. To try and replicate it,
transfer projects like TinyMCE and FCKeditor at the same time.

I have a 512K ADSL connection. Not sure if that helps or not.

If I've understood what you said, the primary and secondary connections are not in sync.
I shouldn't have to keep opening and closing folders on the server just to keep the gui
thread alive during a large queue transfer.

Why should half of the app indicate the connection is active, yet the other half of the
app indicate its not?

Thanks for taking the time to re-examine at this one. I'm more than happy to try and
replicate it again for you and give you whatever data you need.

[Tim Kosse]

The primary and secondary control connections are totally
independant. The "browsing component" in fact gets
disconnected, while the independant "queue component" still
transfers files.

[mrsmiley18]

I understand what you are saying from a technical point of view, but there is no user on
the planet that would consider that behaviour correct.

For starters you cant even select another tranfer after your queue has emptied, because
you have to tell the GUI to reconnect.

Any chance you can explain from a user point of view, and even a HCI (human computer
interaction) point of view, how this behaviour is correct or to be expected by the user?
I've been using computers and file transfer applications for something close to 15 years
now and have never encountered an app that behaved like this. When it happened, I wasn't
even sure if I was supposed to reconnect it while it was transferring, or just wait and
see if it actually was transferring.

If as a user I cant predict what is happening and that my files are actually being
transferred because of the conflicting feedback from the user interface, then all it does
is breed a lack of faith in the interface feedback forcing me to double check the results
every time or switch to another application.

I'm even happy to have it marked as a feature request if you don't want to classify it as
a bug. From a technical stand point, the transfer worked perfectly. From a user stand
point (which I hope is the one that counts), the interface is broken because the feedback
it gives contradicts itself.