sometimes, FZ don't ask for overwrite, just resume it

[tommywu]

I'm not sure this is a bug in original FZ or not,
because I didn't meet this problem when I use the build
download from sourceforge site.
But in my personal build, I've this problem sometimes.

Sometimes, when I add a file for transfer from local to
remote site, if there is a file with same filename
exists, FZ will won't ask me to overwrite it or resume
it (My setting is Ask in option).

I trace this problem for a long time, finally, I found,
sometimes, in CQueueCtrl::SetProgress(), it will set
bTransferStarted to true if
pTransferStatus->bFileTransfer is true. then,
bTriedAutoResume will be true, then the file will be
resume.

If this happen when we've file already in queue, need
to transfer, yes, no problem.
But, if it happen, set bTransferStarted to true, but
there is no file in transfer state, that will cause the
problem I meet.

After trace the code, I found bFileTransfer flag will
set to true in CTransferSocket::UpdateStatusBar() if
m_nTransferState is STATE_STARTED. then FZ will set
bFileTransfer to true always.

But, there are some code will call UpdateStatusBar(),
this problem will happen if
CTransferSocket::CheckForTimeout(), if we just set
m_nTransferState to STATE_STARTED, then FZ will post a
message, then start to transfer it, during the
time,from the time we set it to STATE_STARTED to the
time the file start transfer, if we call
CTransferSocket::CheckForTimeout() again, then
bFileTransfer will set to true before we really start
the transfer. so this file will be consider already in
transfer state, it should be auto resume, not ask us to
choose the action.

My patch will fix this problem, just change the code in

CTransferSocket::UpdateStatusBar(), only change

bFileTransfer to true if the is really in transfer state.

[tommywu]

set bFileTransfer to true only if we need it

[tommywu]

I found some bugs report for this problem, so I think this
will happen in original FileZilla version, not just my
personal patched build version.

[Tim Kosse]

Thanks for spotting this. Though the proper solution is a
little bit different.

It should have been the case, that, if receiving a message
with bFileTransfer set, the transfer is already past the
file exists check.
The problem was, that bFileTransfer was unconditionally set
to true, even for directory listings.
Since messages are posted to the message queue, this created
a timing race. Under some circumstances (which I could never
observe myself) the described faulty behaviour was possible.

Proper fix has been applied to CVS.
Please reopen this tracker item if this problem still
persists. In that case, CQueueCtrl::SetProgress might need
to be fixed somehow.