Custom Query (8170 matches)

If FZ gets a timeout while waiting for a directory listing, it fails and then sits there doing nothing. It should reconnect and retry the directory listing.

This is quite frustrating if you're trying to replicate a directory/file structure on a server. If the server is busy (or a piece-of-junk Windows server), and freezes up instead of sending the directory listing the first time, FZ will just fail and sit there. Then when you come back and notice, you have to delete the entire queue and start the whole queueing-up of files all over again. You waste time with FZ doing nothing, and more time downloading the same directory listings over again.

It seems like it should be pretty simple for FZ to reconnect and retry directory listings, just like it does with downloads and uploads.

Thanks.

This one should be pretty simple. Here's a log that should pretty much explain it all:

Response: 226 Transfer complete. Status: Download successful Status: Disconnected from server [When I returned, I dragged some directories from the remote pane to the local one to download them, then this...] Status: Retrieving directory listing... Command: CWD tutorials Error: Disconnected from server Error: Could not retrieve directory listing

So instead of connecting to the server, *then* sending CWD and proceeding to get the directory listings, it just failed and sat there.

If you're deleting several thousand files from a remote directory, and they are still selected in the remote view pane, the CPU usage remains at 100% and the files are deleted at a rate of about one every two seconds. If you click in the remote pane and deselect all of the files, they start deleting as fast as the server can handle it.

Must be some bug in the window pane code, maybe it's in Windows itself, but a workaround would be to automatically deselect the files if there are more than a certain number of them being deleted and the directory they're being deleted from is the one displayed in the remote pane.