[Pidgin] #2973: AIM file transfer is autocancelled at the receiving end

[Pidgin]

#2973: AIM file transfer is autocancelled at the receiving end
-----------------------------------------+----------------------------------
 Reporter:  mirya                        |       Type:  defect
   Status:  new                          |   Priority:  minor 
Component:  libpurple                    |    Version:  2.1.1 
 Keywords:  file transfer aim cancelled  |    Pending:  0     
-----------------------------------------+----------------------------------
 libpurple-2.1.1 is used. Suppose libpurple-based client is receiving files
 via AIM two other clients are trying to transfer files to it so that the
 2nd (2) starts transfer when the first (1) is already transferring the
 file. An extra condition is that both use client-server (where libpurple-
 based client is server) connection for OSCAR file transfer (that's typical
 situation when libpurple-based client is directly available, but two
 others are behind the NAT).

 This situation results in that libpurple marks the transfer of the (2) as
 remotely cancelled (while (2) didn't really cancelled it).

 I've traced the problem down to the code in ft.c::transfer_cb():

 {{{
 if (condition & PURPLE_INPUT_READ) {
     r = purple_xfer_read(xfer, &buffer);
     if (r > 0) {
         fwrite(buffer, 1, r, xfer->dest_fp);
     } else if(r < 0) {
         purple_xfer_cancel_remote(xfer); /* <-- here it's being cancelled
 */
         return;
     }
 }
 }}}

 The problem is when the conditions above arise purple_xfer_read() itself
 calls read() on xfer->fd and it returns zero (so EOF) for some reason it
 didn't get yet.

 Note: this may be related in some way to #814, but the latter provides no
 information, so I'm unsure it's the same problem. Also, i'm not sure it's
 AIM-only problem.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/2973>
Pidgin <http://pidgin.im>
Pidgin