Server is unable to transfer open files

[ndesle]

When you try to get a file that is open but not
exclusive (it is still possible to do a copy on the
local filesystem for example), FileZilla Server can't
open it and a transfer error is reported. It would be
nice if the server was able to transfer these files. I
need this specifically for transferring open logfiles.
These logfiles are created with the following code:

CStdioFile::Open(filename,CFile::modeCreate |
CFile::modeNoTruncate | CFile::modeWrite |
CFile::shareDenyNone | CFile::typeText , &ex)

I don't know if the server can't open these files by
design or if it is a bug.

Thanks!

[mewf]

Additionally, a more concrete error, like "Could not open
source file" or the like would be useful. I spent yonks this
eveneing trying to work out why a file that had been opend
by Quicktime couldn't upload.

[ndesle]

I've done some tests and it seems that the problem is that
the file is opened by FileZilla Server using

CreateFile(filename, GENERIC_READ, FILE_SHARE_READ, ...)

This means that if the file was already opened by another
process with write access, the call to CreateFile will fail
because it can't guarantee that subsequent calls to open the
file will be read-only. A quick fix in FileZilla Server is
to open the file using

CreateFile(filename, GENERIC_READ,
FILE_SHARE_READ|FILE_SHARE_WRITE, ...). (in file
TransferSocket.cpp, line 943 in the sources that came with
the latest build).

A bit after that code, the server determines the file size
and I assume it works with that number for the remainder of
the file transfer.

If a different process writes to the file afterwards (while
the transfer is in progress), I think you just won't get the
information that was added, and that's fine behaviour by me.

If the other process truncates the file to a shorter length
than what was determined by FileZilla Server, the server
will get a read error at some point. If the error trapping
is OK, this should only result in an aborted transfer, which
is fine behaviour by me again.

If the file is changed (parts overwritten for example) while
the size remains the same or becomes bigger, you will
probably get a successful transfer but a file with mixed
contents (old bits in the front, new bits towards the end of
the file) and it will be corrupt. Serves you right for
reading open files :)

Is this something that could be fixed, or is the risk of
file corruption too high for you? It would be very handy to
download log files of running processes...

[dacash]

This is very annoying bug! Why it was'nt fixed in latest
0.9.5 rls?

[Tim Kosse]

This issue has been fixed years ago.