Free cookie consent management tool by TermsFeed Policy Generator

Opened 10 years ago

Closed 10 years ago

#2247 closed task (done)

Find alternative to SharpZipLib

Reported by: abeham Owned by: ascheibe
Priority: medium Milestone: HeuristicLab 3.3.11
Component: General Version: 3.3.10
Keywords: Cc:

Description (last modified by ascheibe)

We recently tried to do some updating of existing zip files using the sharpziplib that we include in the PluginInfrastructure. What should have been easy turned into a long bug hunting session with the result that this is simply broken for Zip64 stored zip files (the default), but does work with files stored using Zip32.

In this process we noted that the last commit to SharpZipLib was 2 years ago, the last release was more than 4 years ago. It looks like the project has been abandoned.

We should look for alternative Zip libraries that are actively maintained. We saw that in .NET 4.5 the System.IO.Compression namespace got new classes to handle Zip files (in .NET 4 and earlier only Gzip is supported). If this could be used in our project it would be a reason to switch to .NET 4.5 in my opinion.

TODO: * Check if there is a bug in UploadPluginsView.CreateZipPackage()

Attachments (1)

persistence.patch (10.9 KB) - added by ascheibe 10 years ago.
patch that switches persistence from SharpZipLib to IO.Compression

Download all attachments as: .zip

Change History (14)

comment:1 Changed 10 years ago by ascheibe

One other zip lib (that also supports zip64) that I know of is http://dotnetzip.codeplex.com/. But it also seems to be abandoned now, I looked at the changelog, last commit was in 2012.

Last edited 10 years ago by ascheibe (previous) (diff)

comment:2 Changed 10 years ago by gkronber

Discussion in architects meeting: ascheibe checks if projects with external partners are compatible

comment:3 Changed 10 years ago by gkronber

  • Owner changed from architects to ascheibe
  • Status changed from new to assigned

Changed 10 years ago by ascheibe

patch that switches persistence from SharpZipLib to IO.Compression

comment:4 Changed 10 years ago by ascheibe

I measured the time it takes to save and load files with SharpZipLib and IO.Compression.ZipArchive:

Test 12 MB file

TypeTime (in sec, avg. of 3 repetitions
SharpZipLib - Load 7.32
SharpZipLib - Save 7.14
.Net ZipArchive - Load 7.12
.Net ZipArchive - Save 7.21

Test 88 MB file

TypeTime (in sec, avg. of 3 repetitions
SharpZipLib - Load 43.97
SharpZipLib - Save 43.80
.Net ZipArchive - Load 42.61
.Net ZipArchive - Save 43.03

File sizes:

FileExact Size SharpZipLibExact Size .Net ZipArchive
12 MB11.9 MB12.5 MB
88 MB86.5 MB92.9 MB

comment:5 Changed 10 years ago by ascheibe

  • Description modified (diff)

comment:6 Changed 10 years ago by ascheibe

r11650 switched persistence, instance providers, plugin infrastructure and MathJax to System.IO.Compression

comment:7 Changed 10 years ago by ascheibe

r11651 removed SharpZipLib settings and files from the services and slave projects

comment:8 follow-up: Changed 10 years ago by ascheibe

  • Owner changed from ascheibe to gkronber
  • Status changed from assigned to reviewing

While rewritting the code I found something which may be a bug: UploadPluginsView.CreateZipPackage() creates entries in a zip archive, but does not save anything to these entries. Is this ok or is this a bug?

Last edited 10 years ago by ascheibe (previous) (diff)

comment:9 in reply to: ↑ 8 Changed 10 years ago by gkronber

  • Owner changed from gkronber to ascheibe
  • Status changed from reviewing to assigned

Replying to ascheibe:

While rewritting the code I found something which may be a bug: UploadPluginsView.CreateZipPackage() creates entries in a zip archive, but does not save anything to these entries. Is this ok or is this a bug?

This is indeed a bug. The functionality to upload plugins to the server has never been used. Generally the plugin-infrastructure contains a lot of code and complexity that should be removed because we stopped supporting plugin-updates.

comment:10 Changed 10 years ago by ascheibe

  • Owner changed from ascheibe to abeham
  • Status changed from assigned to reviewing

Ok, thank you for the info, then we will clean this up in the future in a seperate ticket.

comment:11 Changed 10 years ago by ascheibe

  • Description modified (diff)

comment:12 Changed 10 years ago by abeham

  • Owner changed from abeham to ascheibe
  • Status changed from reviewing to readytorelease

Changes look good. I tested

  • I looked through the code changes
    • I noticed that in XmlGenerator.cs the compression level was changed from 5 to CompressionLevel.Optimal. This change should only affect the AlgorithmView and ProblemView for the OKB. I noticed that there is no intermediate compression level, it's either fastest or optimal (and none ofc).
  • I quickly tested loading several problem instances, everything worked
  • I tried to find remaining traces of 'sharpzip' or 'ziplib' in the working copy, none found

Good work, please release this after #2280.

comment:13 Changed 10 years ago by ascheibe

  • Resolution set to done
  • Status changed from readytorelease to closed

r11932: merged r11650, r11651 into stable

Note: See TracTickets for help on using tickets.