Ticket #1484880 (closed Bugs: fixed)

Opened 9 months ago

Last modified 4 months ago

Attachments get corrupted on Ubuntu server 64bit 6.06.2 LTS

Reported by: cfritzius Owned by:
Priority: 5 Milestone: 0.2-beta
Component: PHP backend Version: 0.1-stable
Severity: normal Keywords: attachment upload ubuntu
Cc:

Description

Running under Ubuntu server 64bit 6.06.2 LTS attachments uploaded via roundcube client get cut off. It looks as if the file is getting uploaded and no matter what the size of the attachment is, it uploads in under a second. It looks like the file is attached now and ready to be sent so then you send it. The recipient receives the email but the attachment is truncated. *The key here is that no matter what type of file it is, it is truncated to the first 8192 bytes!*

This doesn't appear to be a php memory setting as I've increased those. This is totally reproducible with a fresh install even under VMware. Try it!

FYI...Uploads work fine under CentOS 5.1.

Change History

follow-up: ↓ 2   Changed 9 months ago by lancey

Looks like a PHP misconfiguration. It can't be Roundcube's fault, cause, as you state - all files get uploaded for the same time - this means server issues. Please review your PHP post and upload file limits, as well as any apache limits that might be in effect. Also, please confirm that with another script you can upload files fine on the very same system.

in reply to: ↑ 1   Changed 9 months ago by cfritzius

PHP post is 8M upload is 5M

I tried another upload script and it uploaded every file I threw at it, no problem. Checked the server's upload directory I created and all the files were there...every bit. That led me to do another test... I created a new message in roundcube. Then I attached a file and clicked upload. I immediately checked the temp directory of roundcube and saw that the whole file got uploaded. So that looks good. The problem is when I send the email, the file gets truncated. It's as though roundcube is somehow losing track of the complete attachment. Again, an attachment is sent but only the first 8192 bytes.

I'm not really sure what to look for now.

follow-up: ↓ 4   Changed 9 months ago by thomasb

  • severity changed from major to normal
  • milestone changed from 0.1.1 to later

What PHP version do you run on that Ubuntu 64bit? Looks like a base64_ecode problem to me.

in reply to: ↑ 3   Changed 9 months ago by cfritzius

I'm using PHP 5.1.2, the version that comes with the distro. Is there something I should look for or try in regards to the base64_encode problem?

  Changed 7 months ago by divis

Hi, I have same problem on my Ubuntu 6.06 server, Linux version 2.6.15-51-server. I also tried Debian Etch and upload works fine.

  Changed 7 months ago by null_pointer

I have the same problem with Roundcube 0.1 stable on FreeBSD with PHP Version 5.1.2

The file gets uploaded correctly, I can see it in the temp directory but when the email is sent only 8192 bytes are in the attached file.

  Changed 6 months ago by micha

We had the same problem and it seems that the reason is a wired behavior of the fread()-method in php (http://bugs.php.net/bug.php?id=35859). After some point in the Roundcube-Code, fread is limited to 8K no matter what the real size of the file is. We noticed the problem when including a file with <roundcube:include file="">. We also checked the size of attachments, that were also only 8192 bytes.

From the PHP-Bug-Report:

2) When 5.1.1 was introduced, local file behaviour for fread() changed
to limit to 8K blocks- however if and only if a user stream was opened
before

After changing the database backend (./config/db.inc.php) from "mdb2" to "db",

$rcmail_config['db_backend'] = 'db';

the problem seems to be solved. I think, the backend "mdb2" opened a "userspace stream" and therefor affected all following freads.

Wouldn't it be better to change the following code

$incl = fread($fp, filesize($path));

into

while(!feof($fp)) {
   $incl .= fread($fp, 8192);

?

We are running PHP 5.1.2, Ubuntu 4.0.3

  Changed 4 months ago by alec

  • milestone changed from later to 0.2-beta

  Changed 4 months ago by alec

  • status changed from new to closed
  • resolution set to fixed
  • component changed from Core functionality to PHP backend

May be fixed in r1631. So, please check it and reopen if bug still exists.

Note: See TracTickets for help on using tickets.