on_file_received triggered when aborting upload in clients

[Bram]

When using filezilla, it is possible to suspend uploads by unchecking
'process queue' in the transfer list during an upload. However, this
will trigger a call to on_file_received in pyftpdlib's FTPHandler,
which I subclassed.

I debugged this problem, and it appears that filezilla does *not* send
an "ABOR" command. A posting on a filezilla forum appears to imply
that this is deliberate, and that the server should consider this as
an "ABOR" + "QUIT".

Reference: http://forum.filezilla-project.org/viewtopic.php?f=3&t=16508

When I try with a simple console-based linux client (ncftp), I do see
that it sends an "ABOR" command when I hit ^C during a transfer, and
this will not trigger on_file_received, as expected.

I further debugged the protocol to see if any client would issue a
'complete' command at the end of a transfer, so that the server can
distinguish between an aborted upload (without the ABOR command), and
between a regular upload. But I couldn't find it.

Question is: How to handle this situation? I don't want the server to
trigger the on_file_received event when a user suspends a transfer a
la filezilla, but I don't want to miss completed transfers either.

[Giampaolo Rodolà]

If I properly understood your problem this should not be possible.
Filezilla client aborts an upload by *cleanly* disconnecting the data
socket, without sending ABOR.
For the server this event literally means "the transfer/upload is
finished", hence it replies with 226 and triggers on_file_received()
as expected.

There's no way for the server to know whether the client closed the
connection because the file was entirely sent or because the user hit
an "abort button" because in both cases Filezilla client makes a clean
socket close() call.

I'd say that Filezilla client is misbehaving here, and should use a
different approach when it comes to aborting an upload which is
either:
- use ABOR
- do not use ABOR but use something different than a clean
socket.close() call. Maybe socket.shutdown(), I'm not sure, point is
the data socket should be closed "abruptly" or "not in a clean way".

Note that this problem does not exist for downloads (server sending a
file to client) because in that case the server knows the exact size
of the file and the number of bytes being sent over the socket, hence
it can decide whether replying with 226 or 426 and trigger the right
callback function (on_file_sent() or on_incomplete_file_sent()).
Maybe it would make sense to bring this topic to the attention of
Filezilla client developers.

Hope this helps,

--- Giampaolo

2010/11/9 Bram <avon...@gmail.com>:

> --
> You received this message because you are subscribed to the "Python FTP server library" project group:
> http://code.google.com/p/pyftpdlib/
> To post to this group, send email to pyft...@googlegroups.com
> To unsubscribe from this group, send email to pyftpdlib-...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/pyftpdlib

[Bram]

Thanks for the reply, Giampaolo. You understand my problem correctly,
and I agree with you. I've posted on the filezilla boards to get their
opinion on it:

http://forum.filezilla-project.org/viewtopic.php?f=3&t=18266

Hopefully this will turn up something useful, as it should definitely
be possible to be able to distinguish between incomplete/complete
uploads.

Bram

[Giampaolo Rodola']

I've seen the reply on filezilla forum and I can't reply there because
they "do not accept users with gmail accounts - spam reasons" (bah).
IMHO I think they should definitively use ABOR.
RFC-959 is pretty clear about this.

It seems they are against using ABOR because control channel goes out
of sync:
http://forum.filezilla-project.org/viewtopic.php?f=3&t=16508
...but honestly I haven't properly understood the rationale and also I
don't get how this should apply for uploads in particular.


Regards,

--- Giampaolo