sometimes, FZ don't ask for overwrite, just resume it
|Reported by:||tommywu||Owned by:|
|Keywords:||Cc:||tommywu, Tim Kosse|
|Component version:||Operating system type:|
|Operating system version:|
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
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.