Adding a ZIP file provider

Question

Adding a ZIP file provider

Yves57 opened this issue 9 years ago · 10 comments

I have sent a PR #211 to propose a solution to the hierarchy problem in the Embedded file provider (see #206), but it is not perfect. In parallel, the Embedded file provider has problems to manage correctly dashes in paths (see #184).
Nevertheless it is often useful to "merge" a file tree into one file.
So I suggest to create a ZIP file provider:

It is not so difficult to implement.
It fixes the problems explained above.
A ZIP creation is easy for a user to add in a post-compilation or publish process.

Answer 1 · 2016-07-20T19:35:34.000Z

Any chance for a PR on this issue to be accepted?

Answer 2 · 2016-07-20T19:46:32.000Z

Could this be developed as a 3rd party library? The code for this doesn't necessarily need to live in this repository.

Answer 3 · 2016-07-26T16:19:11.000Z

Agreed with @pranavkm, this can easily be a third party library.

Answer 4 · 2016-07-26T19:50:29.000Z

OK.
For information: https://github.com/AspNetCore-Ext/FileSystem.

Answer 5 · 2016-07-26T21:00:32.000Z

@Yves57 Nice! You can also consider using the https://github.com/AspNet-contrib for the org.

Answer 6 · 2016-07-28T04:57:59.000Z

That's pretty cool and should be contributed to aspnet-contrib

Answer 7 · 2016-07-28T19:43:11.000Z

@davidfowl @muratg I'm fine accepting new projects for aspnet-contrib but I have unfortunately no latitude to review them ATM.

I guess it would help if someone from your team reviewed the current work to see if it's a good candidate for a real world app.

I'm specially concerned about the performance and security implications of reading ZIP files on-the-fly. A from @blowdart would be a must for that kind of contribution.

Answer 8 · 2016-07-28T19:44:47.000Z

Zips are frankly dangerous, due to zip bombs. Now if this was only for trusted input, and not for user upload files I would be ok with it (much like assemblies/embedded files). Assuming it unzipped in memory. And the memory was constrained.

Answer 9 · 2016-07-29T07:02:00.000Z

The first idea is to have a single file to manage (like the embedded file provider idea, but without directory path problems). It is not to compress data.

I have not the right benchmark infrastructure to make tests, but something like:

rawBytes = File.ReadAllBytes(.....);
memoryStream = new MemoryStream(rawBytes);
zipArchive = new ZipArchive(memoryStream);
fileProvider = new ZipFileProvider(zipArchive);

with a not compressed ZIP file may have better performances than a classic PhysicalFileProvider, because all is in memory and works like a file cache.

Answer 10 · 2017-05-12T21:53:24.000Z

We are closing this issue because no further action is planned for this issue. If you still have any issues or questions, please log a new issue with any additional details that you have.