This happens due to the nature of the SFTP protocol, which actually has no concept of 'upload a file' or 'download a file'. It is a POSIX-like remote file system protocol with operations such as open, read, write and close. FileUploaded/FileDownloaded events are raised on close when any data has been written/read.
So when the 'abort transfer' functionality actually closes the remote file, the server cannot distinguish this from a completed transfer (due to the nature of SFTP protocol) and raises the events. Interestingly, if you closed the SFTP session without aborting the transfer, the server would not receive the close request and would not raise the events.
In most scenarios, all we can do is to recommend to Rebex File Server users to modify their transfer logic and trigger the 'done' state differently (for example, upload the file into a .tmp file first, and only consider the transfer complete when it's renamed to the desired file name).
However, your scenario is different because you use Rebex libraries at both ends. We can introduce a custom extension that could be used by the client to indicate whether the data transfer is to be considered aborted. This would work transparently in Rebex SFTP and Rebex File Server scenario. Third-party SFTP clients would still work as before, but they would not be able to indicate this (unless they implement the extension as well, of course). Would you be interested in this solution?
