ZipOutputStream Example

Mar 25, 2011 at 9:33 PM

Hi all, I was wondering if someone could give me a small example of how to create a zip file using the ZipOutputStream class

instead of the ZipFile class. It would be greatly appreciated! I have googled and searched this site for one but I've found nothing.

Thanks!

Coordinator
Mar 26, 2011 at 8:34 AM

Check the documentation.  It's in the CHM, or online it is here:

http://cheeso.members.winisp.net/DotNetZipHelp/html/f93b1af1-124b-3a92-45ad-502bf5c8f065.htm

a link at the bottom of that page ("view TOC") will open up the full table of contents.

Mar 29, 2011 at 7:33 PM

Thanks Cheeso, that helped a lot... but I have one more question.

 

I am trying to put a time stamp on each entry I write to an archive, but I cant figure out how.

I am currently just replacing SharpZipLib with DotNetZip in some already existing code, and this

is the only part I cant figure out.

The old SharpZipLib was using a class called ZipOutputStream as well, but it worked a bit diff....

the old code did something like:

ZipEntry entry = New Zipentry(Path.GetFileName(file));
entry.DateTime = DateTime.Now;
zipOutStream.PutNextEntry(entry);

 

But now, with DotNetZip, it seems as though I am not supposed to use

ZipEntry along with ZipOutputString.... but how do I set a timestamp??

Heres the new:

//zipOutStream.Timestamp = ??????

Any help would be greatly appreciated

Mar 29, 2011 at 8:54 PM

would this work??

ZipEntry entry = zipOutStream.PutNextEntry(file);  

entry.CreationTime = DateTime.Now;                        

zipOutStream = WriteFileToZipOutputStream(zipOutStream, file);

Coordinator
Mar 30, 2011 at 6:15 PM

yes, that would work. From the documentation on PutNextEntry() :

This method returns the ZipEntry. You can modify public properties on the ZipEntry, such as Encryption, Password, and so on, until the first call to ZipOutputStream.Write(), or until the next call to PutNextEntry(). If you modify the ZipEntry after having called Write(), you may get a runtime exception, or you may silently get an invalid zip archive.

I cannot remember what specific situation I was referring to with "you may silently get an invalid zip archive".  That seems like pretty impolite behavior by the library. I'll have to look into that rough edge.  Anyway, don't do that and you'll avoid that problem.

Here's the way to think about it: the entry metadata (like entry name, timestamp, encryption type, password, and so on) gets emitted into the zipfile stream before any of the compressed data.  So, as soon as you call Write() the first time, the metadata gets written, and updating the metadata after that, won't do what you think it should do. 

Regarding your code: not sure why you'd assign zipOutStream variable the the result of the method WriteFileToZipOutStream().  Seems inappropriate, just from my understanding of what you are doing.