Custom Query (8142 matches)

If you sort the remote file list by date ascending (i.e., the most recent file is at the top - two clicks on the "Date" column header), and you have various files with the same date, but different timestamps, then the sort order is wrong: the files created later in that same day are placed down, while they should be at the top of the list! I rephrase: in the situation I described, the days are sorted fine, but the times are inverted. I hope you got the point.

The problem does not occur in the local file list, neither does when the lists are sorted with the most recent file at the bottom.

PS: I'm amazed by your fast response to my feature requests... Great!

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.

sometimes filezilla client gets stuck into a mode where it refuses to:

• after changing the right side directory, update the right side
• click refresh button, refresh the right side

and I don't know if there is any particular sequence that starts this. so my best guess would be to say start looking for logic bugs.