View Issue Details

IDProjectCategoryView StatusLast Update
0025762mantisbtattachmentspublic2019-07-04 03:04
ReporterTomekAP Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product Version2.21.0 
Summary0025762: wrong filesize value in {bug_file} table
Description

filesize column of {bug_file} table stores size of the attachment in bytes. The field is Integer, so it stores values up to 2147483647.
When you upload bigger files, like 3GB, filesize is not correctly stored. MySQL stores max int, PostgreSQL says Integer out of range.
When using MySQL and downloading this attachment, header filesize is sent as well, so browser can download only first 2147483647 bytes of the attachment, ignoring rest, making attachemnt unreadable.

Tagsschema

Activities

dregad

dregad

2019-05-16 04:18

developer   ~0062072

Not questioning the existence of a bug, but I would challenge the need to have attachments that big...

atrol

atrol

2019-05-16 05:42

developer   ~0062074

@TomekAP how did you succeed to upload such big attachments?
To be able to store such big attachments you have to set some parameters to quite high values.
Out of curiosity: What are your settings for PHP upload_max_filesize and post_max_size ?

In case you store the attachments in database you have to increase also MySQL setting max_allowed_packet.

You might get other problems because of it (e.g. out of memory, bad performance caused by swapping), at least if there are multiple users uploading at the same time and/or your server does not have a lot of real memory.

TomekAP

TomekAP

2019-05-16 05:47

reporter   ~0062076

@atrol If server is on LAN it is quite easy. Upload_max_filesize and post_max_size are set to 3GB.
I do not store attachment in database, rather on disk. In database is only metadata(, like filename, filesize, type...)
Performance is not a problem, due to the fact, that attachment is stored on disk.

TomekAP

TomekAP

2019-06-06 04:04

reporter   ~0062214

I think there are two ways of handling it. Make this column bigint (can be unsigned), or (only for some period of time) leave it int, but unsigned..

atrol

atrol

2019-06-06 04:28

developer   ~0062215

@TomekAP it's clear how to handle it, but it can't be handled as a minor 2.x version upgrade, as database schema changes are needed for it.
So I don't think we will see such a change in short term.

I would be good to get some feedback for 0025762:0062072
Could you describe your real use case where having such big attachments is needed?
Until now I have the impression that you use a bugtracker for purposes where a CMS or another tool could be the better one.

TomekAP

TomekAP

2019-06-06 04:32

reporter   ~0062216

I thought, I have written it already. We store there database backups, sometimes with attachments.

TomekAP

TomekAP

2019-07-04 03:04

reporter   ~0062352

There is another possibility, If size is greater than max signed int, than we store in table size as max signed int, but while retrieving the attachment if size in DB is equal to max signed int, than real size will be calculated by size of a file on a disk.