View Issue Details

IDProjectCategoryView StatusLast Update
0025762mantisbtattachmentspublic2019-06-06 08:16
ReporterTomekAP Assigned To 
Status newResolutionopen 
Product Version2.21.0 
Target VersionFixed in Version 
Summary0025762: wrong filesize value in {bug_file} table

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.





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...



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.



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.



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..



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.



2019-06-06 04:32

reporter   ~0062216

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

Issue History

Date Modified Username Field Change
2019-05-15 19:38 TomekAP New Issue
2019-05-16 04:18 dregad Note Added: 0062072
2019-05-16 05:42 atrol Note Added: 0062074
2019-05-16 05:47 TomekAP Note Added: 0062076
2019-06-06 04:04 TomekAP Note Added: 0062214
2019-06-06 04:28 atrol Note Added: 0062215
2019-06-06 04:32 TomekAP Note Added: 0062216
2019-06-06 08:16 atrol Tag Attached: schema