Opened 10 years ago

Closed 4 years ago

Last modified 3 years ago

#8477 closed defect

Files with a size larger than a 32-bit integer can't be transferred.

Reported by: davidgro Owned by:
Milestone: Component: libpurple
Version: 2.5.2 Keywords:
Cc:

Description

Using Pidgin 2.5.2 on Kubuntu I tried to transfer a 4.2GiB file over Bonjour to another PC, also running Pidgin 2.5.2 on Kubuntu. The sending PC - which was x86-64 - stated the correct size, but the receiving PC (i686) thought the file was only 2GiB-1 (2147483647 bytes) which is the max for a signed 32-bit integer - and it actually canceled the transfer (claiming success) when that many bytes had been received. The sending PC correctly reported the cancellation.

I then tried sending a 4.26GiB file back from the 32-bit PC to the 64-bit. This time the sending and receiving PCs both reported the file size as .26GiB (as in 263MiB) which is the size mod 4GiB (another run-in with a 32-bit int). And the transfer stopped "successfully" on both ends after only that much had been sent.

The next thing I tried had an odd result: I sent a 6.8GiB file from the 32-bit PC, and it reported 2.8GiB on the sender and 0 bytes on the 64-bit receiver - so it was x out of 0 bytes while sending, which it called 0% - and Unknown for size and remaining. The receiver did not stop the transfer by itself when the sender stopped at 2.8GiB.

I do not have a second PC with a 64-bit OS to test with. I suspect it would hit a 2 or 4 GiB limit anyway. All file systems involved were ext2 or ext3 and support files over 4GiB.

This issue keeps Bonjour from being a Very useful method for sending large files across a LAN when the sending PC is not setup as a server. (Or would be too annoying to reconfigure for just one file) Please consider fixing this even if that requires an update of the Bonjour IM protocol (It's open right? http://xmpp.org/extensions/xep-0174.html or something? although that doesn't mention files)

Note: I was inspired to test this by a comment in bug 1185, but that bug is about the GUI format strings, and is protocol agnostic. This bug is about the transfers themselves failing and is specific to Bonjour because that is where I feel it is most urgent to fix due to the LAN environment making such transfers more feasible/desirable. (Of course I feel any other other protocols that can be fixed should be)

Attachments (1)

debug20120217.log (19.8 KB) - added by 245T 7 years ago.
windows pidgin output after unsuccessful transfer from ubuntu to wind

Download all attachments as: .zip

Change History (17)

comment:1 Changed 10 years ago by datallah

  • Milestone set to 3.0.0

This isn't fixable without bumping the libpurple API to 3.0.0 because it would require changing the core PurpleXfer structure to use a 64-bit data type for the file size and byte counts paramaters.

comment:2 Changed 9 years ago by datallah

  • Component changed from Bonjour to libpurple
  • Owner datallah deleted
  • Summary changed from Large files can not be transferred via Bonjour to Files with a size larger than a 32-bit integer can't be transferred.

comment:3 Changed 9 years ago by datallah

Ticket #12389 has been marked as a duplicate of this ticket.

comment:4 Changed 8 years ago by MarkDoliner

We should remove the "Unable to transfer file (too large) -- see #8477 for more details" message from si.c in the jabber prpl when this is fixed in the core.

comment:5 Changed 8 years ago by MarkDoliner

Ticket #1185 is related.

comment:6 Changed 8 years ago by qulogic@…

(In 99bc79c8229d3feccd5211b2263e4ea5215b3f62):
Upgrade PurpleXfer? for a 64-bit world.

Prpls and UIs still need to handle this properly though.

Refs #1185. Refs #8477.

comment:7 Changed 8 years ago by qulogic@…

(In f0f3e38fc3b9214c39a0e413f9d2ff5666a389c7):
Update Bonjour for 64-bit file transfers.

Refs #8477.

comment:8 Changed 8 years ago by qulogic@…

(In 5143a681a5993c9573b38887234214d9336297e4):
Update XMPP for 64-bit transfers.

Refs #8477.

comment:9 Changed 8 years ago by qulogic@…

(In 644d46cc49d0ce8b5f7f5a6a517d27ba4f1943b6):
Update MSN for 64-bit file transfers.

Refs #8477.

comment:10 Changed 8 years ago by qulogic@…

(In 6c96608e38f108eb0838102dda480658ba4eabd5):
Update Yahoo for 64-bit file transfers. I'm not really sure if this will work, but since the file sizes are strings, it's should be okay, theoretically. The only exception is this yahoo_xfer_init_15 function, though it seems we never parse have to parse that packet.

Refs #8477.

comment:11 Changed 8 years ago by rekkanoryo

It should be noted that some protocols, like AIM, won't magically support FT for files > 4 GB just from this change--we would need to change our OSCAR FT implementation to something that supports large files.

comment:12 Changed 7 years ago by 245T

While sending a 2,27 GB file from the windows 2.10.1 client in 32bit windows 7 to the version 2.10.0 ubuntu 32bit build over avahi/bonjour in my LAN the file transfer is ended every time at 2'147'483'647 bytes accoring to ubuntu. Windows pidgin says 2'147'582'656 bytes was completed. The receiving client says the file size is 2.00GB when offering the transfer to be accepted or cancelled, and when the transfer fails the sending client says the transfer failed because the recipient cancelled it.

When trying to send the 2,27GB file the other way from ubuntu to windows, the file size is shown as (unknown) on windows in the windows that offers the file and also in the window that shows all file transfers it is shown as unknown. All though "status" under file transfer details is updated and counts the bytes but stays at 0% and "of 0 bytes". Also the progress bar does not move on windows for the large file during the transfer and only states "unknown". On ubuntu the progress bar does work. In the end it seems like the file is transfered 100% from ubuntu to windows, but only ubuntu pidgin says the file transfer was completed. Windows pidgin says nothing and only complains about the transfer having failed because it was cancelled when I disconnect the ubuntu client from the network. The file was transfered completely this time (I compared MD5 sums).

I guess you know these things better than a regular user like me, but I found this http://mail.lon-capa.org/pipermail/lon-capa-admin/2004-August/000613.html while googling the file size.

Changed 7 years ago by 245T

windows pidgin output after unsuccessful transfer from ubuntu to wind

comment:13 Changed 4 years ago by mmcco

Well, this has been around for 6 years, but it's nonetheless a duplicate of #1185 (which has been around for eight years). Because this is an open 3.0 milestone ticket, it should probably be marked as such.

For what it's worth, both tickets have become protocol-agnostic, at least in the comments.

comment:14 Changed 4 years ago by salinasv

  • Status changed from new to pending

I think we can close this ticket since the issue on the core have been already fixed. Let's track prpl specific instances of this on different tickets as needed.

At least, AIM is remaining and it is tracked on #1185

comment:15 Changed 4 years ago by trac-robot

  • Status changed from pending to closed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

comment:16 Changed 3 years ago by Robby

  • Milestone 3.0.0 deleted
Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!