Opened 16 years ago

Last modified 10 years ago

#1286 closed Bug report

Server won't release files after ungraceful xfer interrupt

Reported by: Christian Schroeder Owned by:
Priority: normal Component: FileZilla Server
Keywords: Cc: Christian Schroeder, Tim Kosse
Component version: Operating system type:
Operating system version:



My router reboots a lot, and that's another subject I'm working on elsewhere. Nonetheless, when this happens, and I'm engaged in an upload from my home machine using Client to my work machine running Server, that drop in connection seems to confuse Filezilla server and doesn't let the client side resume transferring that file. All that happens is that the client runs up to the maximum number of permitted retries (very quickly) and then it moves on to the next upload file in the quue, stating the former file had too many retries. It's almost as if the non-graceful transfer termination causes server to not release the handle on the file, and hence it can't open up a new handle (even though it still has the old handle) so that a proper resume could take place.

Even if it wasn't that my router reboots all the time, that's probably something that should be fixed, I would think, as Filezilla should be able to work around that for any number of connection quality issues

Client is 2.2.31. Server is 0.9.23.

Thanks for your help and your time.

Change History (5)

comment:1 by Tim Kosse, 16 years ago

Did the server register the previous connection as disconnected?

comment:2 by Christian Schroeder, 16 years ago


Thanks for your response. No, the server doesn't register the previous connection as disconnected.

comment:3 by Tim Kosse, 16 years ago

In that case you need to wait for the timeout, the server rightfully keeps the file opened till the connection closes on the server side.

(If your router reboots a lot, get a new one)

comment:4 by Christian Schroeder, 16 years ago

Hi again!

Regardless of the fact that my router stinks, one could imagine being in any number of situations (such as a very remote location) where a connection is poor - I've been there! In that case, it would be beneficial to have the server reset itself. I notice in the client you have an option under "connection" that is called "timeout detection:" If zero bytes are transferred within "xx" seconds, assume that the connection timed out and disconnect.

IMHO, adding something like this option to the server would be a simple and fantastic way to solve this problem. It is certainly trivial for the server to open up the file whenever it needs to, so that shouldn't be a deterrent. In my case, I'd set that option to 30 seconds and be done with it. By the time my connection is re-established, Filezilla server would have released the file and would then be able to re-open it on demand.

I really appreciate your time and I'd love your thoughts on this.


comment:5 by Tim Kosse, 16 years ago

The server already has a timeout option.

Note: See TracTickets for help on using tickets.