Opened 10 years ago
Race condition in upload: Collisions with previously failed transfers (?)
|Reported by:||Jörg Zieren||Owned by:|
|Keywords:||upload conflict race||Cc:||expires-06-2013@…|
|Component version:||Operating system type:||Windows|
|Operating system version:||Win7|
I'm experiencing a race condition when uploading. Approx. every 300 files, a file that's being uploaded already exists, and I'm prompted what to do. Typically the file has 0 bytes, sometimes it has <100% size. These files are from previously failed attempts in the same queue - NB that the target directory was empty before.
I'd expect FileZilla to retry failed uploads non-interactively. I'm using 8 concurrent transfers, and the remote server is "flaky" in that it likes to terminate connections randomly every once in a while.
So here's my hypothesis:
1) Thread A uploads file foo, is kicked off the server before upload completes. This leaves the file in the transfer queue (does it?).
2) Thread B finds foo in the transfer queue, tries to upload, and finds the incomplete file created by thread A in 1).
If this is true, the solution might be to do the collision handling cross-threads, i.e. B should know that A just failed to upload foo, and retry non-interactively.
I'm happy to set up a test account on this flaky server. The race is pretty easy to trigger by uploading, say, WordPress (maybe 2 or 3 times).
Also, and I assume this is related, there are files in the "Failed transfers" list. Shouldn't those be retried? (Should I open a new bug for the latter issue, in case it's not related? Or is it even a bug?)