ioFTPD file lock problem

[hsmith1514]

I just set up ioFTPD and it runs nicely, but there's one issue I noticed, and I'm not sure if it's a bug, or just the way ioFTPD works and there's no way around it. When a file is incoming to the server, or being created on the server, that file cannot be transferred out from the server at the same time. ioFTPD reports an error that it could not obtain a lock on the file, and the transfer is aborted. Using any other ftpd programs (servu, raiden, bpftd), that is not a problem and the file can still be transferred out from the server. Is there a way to allow ioFTPD to transfer out files that are currently "in use" on the server like how other ftpds do?

[Yil]

That's working as intended and is actually an added feature. I'm actually surprised other window's based FTPs allow you to download an incoming file. Do they handle things gracefully like glftpd under linux does so that the download continues at the senders speed if you've caught up to the sender, or do they just report end of file and things fail CRC checks on the receiver?

The primary reason I added the locking feature is for zip re-writing. If you have a zip file and you strip out/add NFOs you don't want anybody downloading the file before you've had a chance to perform that action.

The other big reasons are to prevent transfer of incomplete files and preserve speeds. What do you do if the sender closes the connection or if it fails the CRC check? Both of those are relatively rare events, but the far more common case is trying to download an upload in progress and the sender is doing 50k/sec on a 100MB file. Avoiding that scenario is somewhere between impossible (if the slowdown hasn't occurred yet), or hard (examining the uploaders average BW from a particular host)...

[hsmith1514]

The other Windows ftp servers don't handle it gracefully like glftpd. On the Windows servers, if the download happens to catch up to the file being uploaded, the upload continues as normal, but the download from the server breaks at the point where it catches up, and leaves an incomplete file on the target server.
Unfortunately, because of the main purpose for my server, I actually need that feature, and the transfer out catching up with the incoming file is a non issue. Is there some sort of setting or anything that I can adjust to allow this, or is it just one of those "no way around it" things? In my trials with ioFTPD, it seemed way better than the other Windows FTPDs that I've tried, but this one particular feature just happens to be a deal breaker.

[o_dog]

No way around it issue.

[Yil]

You're not the first person looking for that feature, so at some point I may provide a way to disable the file locking based upon the extension of the file, but I really think that only makes sense after I provide a way to handle the catching up problem gracefully. Most people would expect glftpd type behavior...