View Issue Details

IDProjectCategoryView StatusLast Update
0010603mantisbtattachmentspublic2020-01-27 14:36
Reportercas Assigned To 
PrioritynormalSeveritytweakReproducibilityN/A
Status acknowledgedResolutionopen 
Product Version1.2.0a3 
Summary0010603: Automatic compression of uploads for download
Description

Quite often we have attachments that are pretty big, no problem on the home site but on more remote sites pretty annoying.
Was wondering if an automatic compression routine could be integrated into the file upload section.

Steps To Reproduce

Compression routine, build upon php_zip, would look something like:
if (extension_loaded('zip')) {
// Creating a ZIP compressed archive of uploaded file
$outfile = $t_file_name;
$outfile .= ".zip";
// make zip archive
$zip = new ZipArchive();
$zip->open($outFile, ZIPARCHIVE::CREATE);
//add file
$zip->addFile("$t_file_name");
// close archive
$zip->close();
// file to be used for mantis
$t_file_name= $outfile;
// Cleaning up required??
}

Tagspatch

Relationships

has duplicate 0006835 closedvboctor Add in compress option to attached files 

Activities

siebrand

siebrand

2009-06-19 07:55

developer   ~0022194

Updated synopsis. Your report completely differs from your summary.

vboctor

vboctor

2009-06-19 18:39

manager   ~0022201

That's a good idea. We now need a patch for this with the appropriate configuration knobs / documentation updates. Here are my thoughts:

  1. Will this require a flag in the db to reflect if the attachment was compressed or not?
  2. ON/OFF configuration option for new attachments.
  3. Control extensions to exclude (e.g. zip, pdf, jpg, docx, xlsx), i.e. the already compressed formats.
  4. Do we want to support multiple compression formats and use the one that is available and uses best compression ratio? -- that may be an overkill, but I'm dumping my thoughts.

At one point we were also considering auto-conversion of formats like bmp to an impage format with better compression. It would be interesting comparing the zip of a zipped bmp with the size of a jpg, gif, etc.

cas

cas

2009-06-23 03:05

reporter   ~0022231

Last edited: 2009-06-23 03:09

View 2 revisions

Personally I would vote for one compression mechanism, no flag in the DB, set a minumum size , an on/off option and excludes.
One could also revert the process ( less userfriendly ) and define types that are allowed to be uploaded so an include list (which then could be zip,gz,tar,jpg,.......)

vboctor

vboctor

2009-06-23 03:37

manager   ~0022235

I believe that a flag is required for the following reasons:

  1. Admin upgrades MantisBT to version that includes this feature, existing attachments are not compressed, new ones are. If we don't have a flag, then we need to add an upgrade step to compress all attachments which can be a length process that I don't think is worth doing.

  2. Admin installed MantisBT and started uploading attachments, 3 months later, the admin installed a compression plugin. All new attachments are compressed, old ones are not. Note that there is no upgrade scenario here to hook into the upgrade process.

  3. The admin adds pptx to the list of attachments to be skipped. Note that in the past these were compressed.

  4. The compressed flag will allow us to use the size threshold you are recommending. Although in my mind, if we compress small attachments and they increase in site, it is no big deal. However, I think the exclusion list is useful.

I agree with 1 compression mechanism (as I mentioned in my earlier comment, this may be an overkill).

dhx

dhx

2009-06-23 06:21

reporter   ~0022237

I don't really see a need for this when we can just use gzip compression for server <-> client communication. The limiting factor is almost never going to be the amount of disk space you have available to serve up files - it'll be CPU usage and memory consumption... and zip compression certainly doesn't help limiting those two factors. Unless of course you're trying to save space in the database... in which case, isn't there an on-the-fly approach we can use in PHP to do this (as opposed to writing zip files to the disk and reading them back)?

Still, I would disagree with compressing files because of CPU usage concerns and the availability of better traditional solutions such as mod_gzip, etc.

cas

cas

2009-06-23 09:46

reporter   ~0022242

For me it is not about diskspace, it is about the time it takes to view a bmp-file on a remote location. They sometimes are over 2mb whereas compressed they might be just 50k.
If GZIP would do this then it would be a question of adding "ob_start("ob_gzhandler");" to filke_download.php in order to achieve what I had in mind.
Is that assumption correct?

cbradney

cbradney

2009-07-04 17:50

reporter   ~0022392

Last edited: 2009-07-04 18:40

View 2 revisions

I would vote for a one off additional process of zip/unzip for all existing bug attachments too. When a project uses a lot of text files (xml) like Scribus, we have a lot of them sitting around that could be made a lot smaller for all historical bugs, as well as turning on the compression for new bugs.

sandyj

sandyj

2020-01-27 14:36

reporter   ~0063521

Another vote for this feature.

Issue History

Date Modified Username Field Change
2009-06-18 02:52 cas New Issue
2009-06-19 07:55 siebrand Note Added: 0022194
2009-06-19 07:55 siebrand Summary Large Attachments => Automatic compression of uploads for download
2009-06-19 18:35 vboctor Tag Attached: patch
2009-06-19 18:39 vboctor Note Added: 0022201
2009-06-19 18:39 vboctor Status new => acknowledged
2009-06-23 03:05 cas Note Added: 0022231
2009-06-23 03:09 cas Note Edited: 0022231 View Revisions
2009-06-23 03:37 vboctor Note Added: 0022235
2009-06-23 06:21 dhx Note Added: 0022237
2009-06-23 09:46 cas Note Added: 0022242
2009-07-04 17:31 vboctor Relationship added has duplicate 0006835
2009-07-04 17:34 vboctor Category feature => attachments
2009-07-04 17:50 cbradney Note Added: 0022392
2009-07-04 18:40 cbradney Note Edited: 0022392 View Revisions
2020-01-27 14:36 sandyj Note Added: 0063521