o_dog: Because you only see this issue with FXP transfers it makes diagnosing it harder. I'm still not convinced there is a server error. However, there are 2 possible issues I'm looking at right now. The first is a slow sender and ioFTPD thinks the connection is still active. V7.5 will offer you the option to change the per-packet timeout to whatever you want in case that helps. On the to-do list for a v7.6+ release is FXP progress reporting so you could verify that it's still in progress but because that might affect my socket stability work I decided against it for the next release.
I've also found a huge bug! In my 10 connection at a time upload case for stefano I found that I was getting some weird results. It turns out the server was passing the port re-use flag to the bind function which means it could give out the same port to 2 different PASV calls with the possible result that 2 files would get switched when uploaded! I verified this goes back to 5.8.5 so it's nothing new. If you randomize the passive port range and use say 50 ports the chances are slim but it can happen. If you don't randomize (Random = FALSE for a Device) it's nearly impossible with a large range so that's a good work-around right now. My test case with just 2 randomize passive ports and 10 brand new connections all at the same time had issues, but that's why I try weird config test cases. I just don't personally use a FTP client that does multiple connections all at once so it never popped up before...
The reason this might be important is if you have a small passive port range and someone or many people all starting uploads at the same time it's possible the server thinks the transfer is in progress because it actually is! Just not yours... You might be able to confirm this if you can check the xferlog to see if the file that you got stuck on eventually reports itself in the transfer log. You can manually try to abort the transfer, which should work, and then check the log right away as well to see what it says. Check that it was being sent from the host you were FXPing from or that it was still in progress by looking at the total transfer time field. Another clue would be uploads to a .sfv verified dir and the server reporting a crc failure.
This is a bad error for non-sfv dirs to handle though. I can't believe we've gone this long without people diagnosing the problem and *****ing about it...
pion: I'm pretty convinced at this point that using my custom nxmydb and libmysql probably means neither are at fault. I don't know why you have this problem so often yet, but I've got 2-3 really good changes in v7.5 and we'll have to hope it helps. The restart logic is VASTLY better so even if not fixed it will be all automatic soon.
I still need to finish up a couple of things but should be out in a day or so provided I don't find anything new. I've probably put over 60 hours in the last 2 weeks alone on this, so I'm working as fast as I can
