jaime-olivares / zipstorer Goto Github PK
View Code? Open in Web Editor NEWA Pure C# Class to Store Files in Zip
License: MIT License
A Pure C# Class to Store Files in Zip
License: MIT License
Version: 2.35 (March 14, 2010)
Your helper file is very much useful, I have used in my 3-5 projects but when I used in recent project where zipping was of more than 6gb folder, zip file was generating successfully but unzipping was making issue in checksum error.
After going through your code and comments I found that support for larger sizes file you have changed the WriteEndRecord parameter size but not changed in close function to send the value for the same so I have changed some little two things in two lines of your code.
Please change the data type in ### close() function at line### 334, 335 from uint to long as when there is bigger sizes files the stream position is at greater than the uint max size.
Please look the same and do changes for making this more awesome successful code.
/// <summary>
/// Updates central directory (if pertinent) and close the Zip storage
/// </summary>
/// <remarks>This is a required step, unless automatic dispose is used</remarks>
public void Close()
{
if (this.Access != FileAccess.Read)
{
long centralOffset = this.ZipFileStream.Position;
long centralSize = 0;
if (this.CentralDirImage != null)
this.ZipFileStream.Write(CentralDirImage, 0, CentralDirImage.Length);
for (int i = 0; i < Files.Count; i++)
{
long pos = this.ZipFileStream.Position;
this.WriteCentralDirRecord(Files[i]);
centralSize += (uint)(this.ZipFileStream.Position - pos);
}
if (this.CentralDirImage != null)
this.WriteEndRecord(centralSize + (uint)CentralDirImage.Length, centralOffset);
else
this.WriteEndRecord(centralSize, centralOffset);
}
if (this.ZipFileStream != null && !this.leaveOpen)
{
this.ZipFileStream.Flush();
this.ZipFileStream.Dispose();
this.ZipFileStream = null;
}
}
After changing code then to file extraction giving error of checksum please look in this issue.
I'm trying to use this class in a small WCF project where I don't want to add another 3rd party lib.
I want to use the stream mode for packaging and then send the zip stream to another machine. Unfortunately the internal zipfilestream is closed and disposed within the Close()
method. If I don't close the zip, then the EndRecord
is not written. But when I close the zip then the underlying stream is closed.
My suggestion is to set a flag when a filename is provided for Open()
or Create()
. When this is set, then ZipFileStream.Dispose();
and ZipFileStream = null;
in function Close()
should be omitted.
I have a working solution here and can provide a pull request later.
Hello,
I'm using ZipStorer with sometimes large zip archives. It could happen that a download of a large zip archive (above 1GB) is interrupted and a corrupt zip archive without central direcotry structure is caused. When opening such a file it takes an indefinitely long time (definitely longer than 10 minutes for 2GB) for the ZipStorer to search the whole zip for a "End of central directory record" (cause it did not exist).
Is there the possibility to get an earlier feedback that the zip archive is corrupted. A possible solution could be to only search in the last MB of the zip for this record? The only variable size in this record is a "comment" value.
It would be valuable to get a quicker feedback of a broken zip.
I'm using zipstorer.vb in an application to open and save EPUB files. I've discovered that the saving process is crashing in the DateTimeToDosTime function when files in the EPUB have "weird" dates. (Note that they open fine.)
The error that is given is "Arithmetic operation resulted in an overflow". If I check the value of the variable _dt, I get the following values:
_dt = #12/31/2107 11:00:00 PM#
_dt.Second = 0
_dt.Minute = 0
_dt.Hour = 23
_dt.Day = 31
_dt.Month = 12
_dt.Year = 2107
When I look at the EPUB file in 7-zip, the file that zipstorer is currently trying to save to the stream has a date modified 1980-01-01 07:00 (even though the created date is 2011-06-02 05:35).
Any idea what's causing the overflow?
Can you add the proper date/time in the extended header instead of the brain dead dos format date/time?
Unable to find MonoPosixHelper
DllNotFoundException: MonoPosixHelper
at System.IO.Compression.DeflateStream:CreateZStream
at System.IO.Compression.DeflateStream..ctor
at System.IO.Compression.DeflateStream..ctor
at System.IO.Compression.DeflateStream:.ctor
at System.IO.Compression.ZipStorer.ExtractFile (ZipFileEntry _zfe, System.String _filename)
So better to use SharpZipLib
The FxCop static analysers are reporting CA1028 against the following line in ZipStorer.cs:
public enum Compression : ushort
These state that
Even though you can change this underlying type (from System.Int32), it is not necessary or recommended for most scenarios. No significant performance gain is achieved by using a data type that is smaller than Int32. If you cannot use the default data type, you should use one of the Common Language System (CLS)-compliant integral types, Byte, Int16, Int32, or Int64 to make sure that all values of the enumeration can be represented in CLS-compliant programming languages.
So, please consider making one of the following changes:
ushort
specifically is relied upon and required, then change its underlying type to System.UInt16
, otherwiseSystem.Int32
.Thanks.
I am using your code in https://github.com/arkypita/LaserGRBL
Your minimal library is exactly what I need to download new version from internet and unzip them to perform auto-update. Thank you!
To fix this issue, just add in "Store":
if (_source.Length == 0)
{
_zfe.FileSize = 0;
_zfe.CompressedSize = 0;
_zfe.Crc32 = 0;
_zfe.Method = Compression.Store;
return _zfe.Method;
}
Hello while using the class ZipStorer as a standalone, versions 3.4.0 (August 4, 2017) and also the current version in the repository, I run into a race condition.
In my application I do the following:
A
in which the zip contents will be putA
A
in B
The problem is that sometimes the step 4 fails with System.IO.IOExceptionAccess to the path 'A' is denied
. Further information
Here follows a proof of concept and the zip file with some content in it that I used to reproduce the issue.
public void AccessDeniedPoc()
{
// preparation
var cycles = 300;
var releaseZipFpath = "C:\\fixtures\\tozip.zip";
var playgroundFolderFpath = "C:\\fixtures\\playground";
var extractFolderPath = Path.Combine(playgroundFolderFpath, "extarget");
var moveTargetFolderPath = Path.Combine(playgroundFolderFpath, "mvtarget");
for (int i = 0; i < cycles; i++)
{
if (Directory.Exists(extractFolderPath)) Directory.Delete(extractFolderPath, true);
if (Directory.Exists(moveTargetFolderPath)) Directory.Delete(moveTargetFolderPath, true);
Directory.CreateDirectory(extractFolderPath);
MemoryStream memoryStream = new MemoryStream();
using (FileStream fileStream = new FileStream(releaseZipFpath, FileMode.Open, FileAccess.Read))
{
fileStream.CopyTo(memoryStream);
}
using (var zip = ZipStorer.Open(memoryStream, FileAccess.Read))
{
List<ZipStorer.ZipFileEntry> dir = zip.ReadCentralDir();
foreach (ZipStorer.ZipFileEntry entry in dir)
{
string currPath = Path.Combine(extractFolderPath, entry.FilenameInZip);
if (currPath.EndsWith("/"))
{
Directory.CreateDirectory(currPath);
}
else
{
zip.ExtractFile(entry, currPath);
}
}
}
// moving folder
try
{
Directory.Move(extractFolderPath, moveTargetFolderPath);
}
catch (Exception e)
{
Console.WriteLine("exception on " + i);
throw;
}
}
}
Could you please take a look at it and help me go through it? Am I doing something wrong or is there a problem in ZipStorer
? Thank you
Excellent tool BTW. Comments in zip entries is a unique capability. A user of my software reports that his zip file gets corrupted when removing the last entry (Win 7, NET 4.0). I have not reproduced this in my testing, so I am puzzled - maybe a timing or access issue? I am not using streams. An ideas? Here is my code, which is nearly the same as in example:
// Function to delete one zip file entry, by matching a filename. All will be uppercase.
private void RemoveOne(string aname)
{
List<ZipStorer.ZipFileEntry> removeList = new List<ZipStorer.ZipFileEntry>();
// Look for the entry that matches the given name
foreach (ZipStorer.ZipFileEntry entry in zipdir)
{
if (Path.GetFileName(entry.FilenameInZip) == aname)
{
removeList.Add(entry);
break;
}
}
// double check
if (removeList.Count > 0)
{
ZipStorer.RemoveEntries(ref zip, removeList); // list is just one
// the close and reopen is done within the removeentries method, but somehow not quite right?
}
// should be done. I think I need this.
zipdir = zip.ReadCentralDir(); // needed? what happen when last entry is removed?
}
Hi all, I am planning to give this old library a new life. Please suggest features that you may not found in the existing Microsoft APIs. Take into account that this is a small library without dependencies (with exception of the Deflate class), so I won't be inclined to add very complex functionalities. Thanks.
I propose a subj, by replacing line 454 with the following:
if (!String.IsNullOrEmpty(path) && !Directory.Exists(path))
Hi,
First i have to say nice work. I have a problem when i extract all files i would like to remove zip file afterwords, but it wont let me and zip is being lock by this class. Im using zip.dispose and also zip.close, but still it is locked. Any help pls ?
I found an issue with the DosTimeToDateTime routine. I have a KMZ file from which I wanted to extract the underlying KML file. However, the KML file does not have any attributes/metadata specified. This causes the class to crash when calling the DosTimeToDateTime routine with 0 as the argument. I modified the routine as following:
private DateTime DosTimeToDateTime(uint _dt)
{
int year = (int)(_dt >> 25) + 1980;
int month = (int)(_dt >> 21) & 15;
int day = (int)(_dt >> 16) & 31;
int hour = (int)(_dt >> 11) & 31;
int minute = (int)(_dt >> 5) & 63;
int second = (int)(_dt & 31) * 2;
return new DateTime(year, month == 0 ? 1 : month, day == 0 ? 1 : day, hour, minute, second);
}
Maybe returning DateTime.Now would be better. Either way, in case the modify date/time stamp is missing, the original code crashes.
Hi,
I added some basic support for async-operation.
Its in my fork. Feel free to pull it in here.
I'll test it a bit during development.
Greetings
I'm not good programmer, so I can't describe the issue will .. this exception showing with some files, not with all, and fire from DosTimeToDateTime Function
System.ArgumentOutOfRangeException: 'Hour, Minute, and Second parameters describe an un-representable DateTime.'
hi and thanks for the very useful utility. I am using it to manipulate .idml files which are compressed folders for adobe indesign files. Extracting a file from the directory works just fine.
My goal is to replace a file in the directory. To do this I figures I should first remove the entry and then add a new one.
I am facing a problem when trying to remove an entry. After executing RemoveEntries()
, the entry is still there. I can check because after running, the number of entries didn't change. However, RemoveEntries()
is returning true
every time.
ZipStorer zip = ZipStorer.Open(idmlPath, FileAccess.Write);
List<ZipStorer.ZipFileEntry> removeList = new List<ZipStorer.ZipFileEntry>();
// Look for the desired file to replace
foreach (ZipStorer.ZipFileEntry entry in zip.ReadCentralDir())
{
if (Path.GetFileName(entry.FilenameInZip) == Path.GetFileName(archivePath))
{
removeList.Add(entry);
}
}
if (removeList.Count > 0)
{
bool result = ZipStorer.RemoveEntries(ref zip, removeList);
}
zip.Close();
not sure if this is a bug or I am doing something wrong. Assuming that the ZipStorer
object should be opened with write access.
Hi!
First of all, thank you very much for your effort writing this software!
I need it, because the regular "ZipArchive" does not
support storing without compression. It has a flag "CompressionLevel.NoCompression", that still produces compressed files. This is really weird and is discussed here also: https://stackoverflow.com/questions/38704792/set-ziparchiveentry-compressionlevel-to-compressionlevel-nocompression-not-work?rq=1
I need storing for a file format, which we "invented".
Anyway, I have successfully implemented your class. Storing of a text as a stream works (I did it like in your example), but adding Image (Bitmap) objects from memory through stream produces 0 byte entries in the ZIP.
I paste lines of code here, maybe you could help?
So, what I do: I create the ZIP archive, then I add a MemoryStream to it, in which I have stored the "tileData", which basically is an Image Object, which I read before from a Tiff file into this object.
In the attached image, you see the ZIP archive, which I opened. The entries of the images are there, but with 0 bytes.
zip = System.IO.Compression.ZipStorer.Create(sziFilename2, "SZI (c) Smart In Media"); MemoryStream tileFile = new MemoryStream(); tileData.Save(tileFile, ImageFormat.Jpeg); zip.AddStream(ZipStorer.Compression.Store, "test.jpeg", tileFile, DateTime.Now, ""); tileFile.Close(); zip.Close();
Hi! I've tried to unzip the attached archive cert_21.zip with the latest version available at the moment. It fails with exception System.IO.InvalidDataException, but this archive is successfully being unzipped on my MacOS using default Archive Utility (not checked with other tools). My coworker told me that he created this archive with php ZipArchive.
With debugger I see that the problem occurs on these lines:
// check if comment field is the very last data in file
if (commentPosition + commentSize != this.ZipFileStream.Length)
return false;
1952 + 0 != 2208
If I disable these lines, the archive is being unzipped (didn't check if it's done correct). I execute code in Xamarin.iOS project.
Please, take a look and check if this is a bug.
p.s. also zipinfo utility doesn't complain about this archive.
zipinfo -v cert_21.zip
Archive: cert_21.zip
There is no zipfile comment.
End-of-central-directory record:
-------------------------------
Zip archive file size: 2208 (00000000000008A0h)
Actual end-cent-dir record offset: 1930 (000000000000078Ah)
Expected end-cent-dir record offset: 1930 (000000000000078Ah)
(based on the length of the central directory and its expected offset)
This zipfile constitutes the sole disk of a single-part archive; its
central directory contains 6 entries.
The central directory is 480 (00000000000001E0h) bytes long,
and its (expected) offset in bytes from the beginning of the zipfile
is 1450 (00000000000005AAh).
Central directory entry #1:
---------------------------
header.key
offset of local header from start of archive: 0
(0000000000000000h) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
compression sub-type (deflation): normal
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2021 Jun 9 12:47:38
file last modified on (UT extra field modtime): 2021 Jun 9 12:47:38 local
file last modified on (UT extra field modtime): 2021 Jun 9 09:47:38 UTC
32-bit CRC value (hex): 1daf4c3e
compressed size: 719 bytes
uncompressed size: 898 bytes
length of filename: 10 characters
length of extra field: 24 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (100644 octal): -rw-r--r--
MS-DOS file attributes (00 hex): none
The central-directory extra field contains:
- A subfield with ID 0x5455 (universal time) and 5 data bytes.
The local extra field has UTC/GMT modification/access times.
- A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
01 04 d0 07 00 00 04 17 27 00 00.
There is no file comment.
Central directory entry #2:
---------------------------
masks.key
offset of local header from start of archive: 787
(0000000000000313h) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2021 Jun 9 12:47:38
file last modified on (UT extra field modtime): 2021 Jun 9 12:47:38 local
file last modified on (UT extra field modtime): 2021 Jun 9 09:47:38 UTC
32-bit CRC value (hex): 89e6e4e8
compressed size: 88 bytes
uncompressed size: 88 bytes
length of filename: 9 characters
length of extra field: 24 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (100644 octal): -rw-r--r--
MS-DOS file attributes (00 hex): none
The central-directory extra field contains:
- A subfield with ID 0x5455 (universal time) and 5 data bytes.
The local extra field has UTC/GMT modification/access times.
- A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
01 04 d0 07 00 00 04 17 27 00 00.
There is no file comment.
Central directory entry #3:
---------------------------
masks2.key
offset of local header from start of archive: 942
(00000000000003AEh) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2021 Jun 9 12:47:38
file last modified on (UT extra field modtime): 2021 Jun 9 12:47:38 local
file last modified on (UT extra field modtime): 2021 Jun 9 09:47:38 UTC
32-bit CRC value (hex): 911b3453
compressed size: 88 bytes
uncompressed size: 88 bytes
length of filename: 10 characters
length of extra field: 24 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (100644 octal): -rw-r--r--
MS-DOS file attributes (00 hex): none
The central-directory extra field contains:
- A subfield with ID 0x5455 (universal time) and 5 data bytes.
The local extra field has UTC/GMT modification/access times.
- A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
01 04 d0 07 00 00 04 17 27 00 00.
There is no file comment.
Central directory entry #4:
---------------------------
name.key
offset of local header from start of archive: 1098
(000000000000044Ah) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2021 Jun 9 12:47:38
file last modified on (UT extra field modtime): 2021 Jun 9 12:47:38 local
file last modified on (UT extra field modtime): 2021 Jun 9 09:47:38 UTC
32-bit CRC value (hex): aa04b7fa
compressed size: 11 bytes
uncompressed size: 11 bytes
length of filename: 8 characters
length of extra field: 24 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (100644 octal): -rw-r--r--
MS-DOS file attributes (00 hex): none
The central-directory extra field contains:
- A subfield with ID 0x5455 (universal time) and 5 data bytes.
The local extra field has UTC/GMT modification/access times.
- A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
01 04 d0 07 00 00 04 17 27 00 00.
There is no file comment.
Central directory entry #5:
---------------------------
primary.key
offset of local header from start of archive: 1175
(0000000000000497h) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2021 Jun 9 12:47:38
file last modified on (UT extra field modtime): 2021 Jun 9 12:47:38 local
file last modified on (UT extra field modtime): 2021 Jun 9 09:47:38 UTC
32-bit CRC value (hex): ffe813bd
compressed size: 68 bytes
uncompressed size: 68 bytes
length of filename: 11 characters
length of extra field: 24 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (100644 octal): -rw-r--r--
MS-DOS file attributes (00 hex): none
The central-directory extra field contains:
- A subfield with ID 0x5455 (universal time) and 5 data bytes.
The local extra field has UTC/GMT modification/access times.
- A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
01 04 d0 07 00 00 04 17 27 00 00.
There is no file comment.
Central directory entry #6:
---------------------------
primary2.key
offset of local header from start of archive: 1312
(0000000000000520h) bytes
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 1.0
compression method: none (stored)
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2021 Jun 9 12:47:38
file last modified on (UT extra field modtime): 2021 Jun 9 12:47:38 local
file last modified on (UT extra field modtime): 2021 Jun 9 09:47:38 UTC
32-bit CRC value (hex): e53582c5
compressed size: 68 bytes
uncompressed size: 68 bytes
length of filename: 12 characters
length of extra field: 24 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (100644 octal): -rw-r--r--
MS-DOS file attributes (00 hex): none
The central-directory extra field contains:
- A subfield with ID 0x5455 (universal time) and 5 data bytes.
The local extra field has UTC/GMT modification/access times.
- A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
01 04 d0 07 00 00 04 17 27 00 00.
There is no file comment.
Firstly, terrific job with ZipStorer!
I'm just using zip storer a stream that does not support seeking. It looks like UpdateCrcAndSizes sets the position property of a stream, even when CanSeek = false.
According to https://msdn.microsoft.com/en-us/library/system.io.stream.canseek(v=vs.110).aspx "If a class derived from Stream does not support seeking, calls to Length, SetLength, Position, and Seek throw a NotSupportedException."
Sadly, checking the code I'm not sure how to work around it, short of wrapping it in say a buffered stream. Any thoughts?
hello , i want save to MemoryStream , export the file by external code . but found that the export of the file can not be properly extracted.
public byte[] Compress(byte[] bytes)
{
Stream stream = new MemoryStream();
ZipStorer zip = ZipStorer.Create(stream, string.Empty);
Stream zipData = new MemoryStream(bytes);
zip.AddStream(ZipStorer.Compression.Deflate ,"default", zipData, DateTime.Now, string.Empty);
bytes = zip.Close(); // i change this code, make it can return byte[]
return bytes;
}
Raise this error
No data is available for encoding 437. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method.
as workaround i comment the lines
private static Encoding DefaultEncoding = Encoding.UTF8/* Encoding.GetEncoding(437)*/;
Hi!
Thanks for awesome tool to work with zip! Unfortunately i ran into a problem when reading the zip64 file.
According with zip format specification fields in zip64 extended information record MUST only appear if the corresponding Local or Central directory record field is set to 0xFFFF or 0xFFFFFFFF
This issue may be fixed by change // ZIP64 Information
block in ReadExtraInfo
function to this:
if (extraId == 0x0001) // ZIP64 Information
{
int extraOffset = 4;
if (_zfe.FileSize == 0xFFFFFFFF)
{
_zfe.FileSize = BitConverter.ToInt64(buffer, pos + extraOffset);
extraOffset += 8;
}
if (_zfe.CompressedSize == 0xFFFFFFFF)
{
_zfe.CompressedSize = BitConverter.ToInt64(buffer, pos + extraOffset);
extraOffset += 8;
}
if (_zfe.HeaderOffset == 0xFFFFFFFF)
{
_zfe.HeaderOffset = BitConverter.ToInt64(buffer, pos + extraOffset);
}
}
And calculate zfe.FileOffset
after invocation ReadExtraInfo
.
But CreateExtraInfo
should be rewrited to.
Hey,
I noticed the library does not check the file stamp to determine if the filew passed in is a Zip file. I passed in a .Rar archive by mistake and it started parsing away and crashing eventually. I created a simple fix that checks for the ZIP filestamp (0x50,0x4b,0x03, 0x04) before parsing to avoid that. I hope I am notr missing anything ?
How do i make Directory Entries?
Thank you very much for developing ZipStorer. I have used it in several apps and until now I haven't encountered a problem.
In my last project I needed check a content of archive before add new files to avoid duplicate file names in that archive. I find out if I read an archive content and then I add no files into it to avoid duplicates causes an archive corruption.
See my test code. After first run a new archive is created. After second run an existing archive is opened and after check for duplicate file names in archive no files are added. And after that the whole archive is corrupted! And I opened only an existing archive, then I read its content, I wrote down no files and in the end I close it.
Do you have an idea where the problem might be?
const string archiveFilePath = @"C:\Temp\test.zip";
var archiveFileExists = File.Exists(archiveFilePath);
using (var zipArchive = archiveFileExists
? ZipStorer.Open(archiveFilePath, FileAccess.ReadWrite)
: ZipStorer.Create(archiveFilePath, "TestArchive"))
{
var zipFileEntries = archiveFileExists
? zipArchive.ReadCentralDir()
: new List<ZipStorer.ZipFileEntry>();
for (int i = 0; i < 10; i++)
{
if (zipFileEntries.Any(e => e.FilenameInZip == $"TestFile_{i + 1:00}.txt")) continue;
using (var memoryStream = new MemoryStream())
using (var streamWriter = new StreamWriter(memoryStream))
{
streamWriter.WriteLine("TEST!");
streamWriter.Flush();
memoryStream.Seek(0, SeekOrigin.Begin);
zipArchive.AddStream(ZipStorer.Compression.Deflate, $"TestFile_{i + 1:00}.txt", memoryStream,
DateTime.Now, string.Empty);
}
}
}
The extract routine in the demo class does not work properly with the internal directory structure of the zip file. I tried extracting a zip file containing multiple shape files. The shape file were organized by folders, each folder containing shape files with the same name. When I ran the demo extraction I ended up with only one set of the shape files in a single folder (the other sets were overwritten by newer files of the same name). Basically, my suggestion is that the following line
path = Path.Combine(TextTargetFolder.Text, Path.GetFileName(entry.FilenameInZip));
is changed to
path = Path.Combine(TextTargetFolder.Text, entry.FilenameInZip);
to preserve the internal zip directory structure.
Old version Zipstorer did not support big files if added file size was over uint range :). I have not tested this new version but I had feeling, when I looked source code, that there is same problem. You should check this out.
How do I extract to a folder not a file.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.