// ZipFile.cs

//

// Copyright (c) 2006-2010 Dino Chiesa

// All rights reserved.

//

// This module is part of DotNetZip, a zipfile class library.

// The class library reads and writes zip files, according to the format

// described by PKware, at:

// http://www.pkware.com/business_and_developers/developer/popups/appnote.txt

//

//

// There are other Zip class libraries available.

//

// - it is possible to read and write zip files within .NET via the J# runtime.

// But some people don't like to install the extra DLL, which is no longer

// supported by MS. And also, the J# libraries don't support advanced zip

// features, like ZIP64, spanned archives, or AES encryption.

//

// - There are third-party GPL and LGPL libraries available. Some people don't

// like the license, and some of them don't support all the ZIP features, like AES.

//

// - Finally, there are commercial tools (From ComponentOne, XCeed, etc). But

// some people don't want to incur the cost.

//

// This alternative implementation is **not** GPL licensed. It is free of cost, and

// does not require J#. It does require .NET 2.0. It balances a good set of

// features, with ease of use and speed of performance.

//

// This code is released under the Microsoft Public License .

// See the License.txt for details.

//

//

// NB: This implementation originally relied on the

// System.IO.Compression.DeflateStream base class in the .NET Framework

// v2.0 base class library, but now includes a managed-code port of Zlib.

//

// Thu, 08 Oct 2009 17:04

//

using System;

using System.IO;

using System.Collections.Generic;

using Interop = System.Runtime.InteropServices;

namespace Ionic.Zip

{

/// <summary>

/// The ZipFile type represents a zip archive file.

/// </summary>

///

/// <remarks>

/// <para>

/// This is the main type in the DotNetZip class library. This class reads and

/// writes zip files, as defined in the <see

/// href="http://www.pkware.com/documents/casestudies/APPNOTE.TXT">specification

/// for zip files described by PKWare</see>. The compression for this

/// implementation is provided by a managed-code version of Zlib, included with

/// DotNetZip in the classes in the Ionic.Zlib namespace.

/// </para>

///

/// <para>

/// This class provides a general purpose zip file capability. Use it to read,

/// create, or update zip files. When you want to create zip files using a

/// <c>Stream</c> type to write the zip file, you may want to consider the <see

/// cref="ZipOutputStream"/> class.

/// </para>

///

/// <para>

/// Both the <c>ZipOutputStream</c> class and the <c>ZipFile</c> class can

/// be used to create zip files. Both of them support many of the common zip

/// features, including Unicode, different compression methods and levels,

/// and ZIP64. They provide very similar performance when creating zip

/// files.

/// </para>

///

/// <para>

/// The <c>ZipFile</c> class is generally easier to use than

/// <c>ZipOutputStream</c> and should be considered a higher-level interface. For

/// example, when creating a zip file via calls to the <c>PutNextEntry()</c> and

/// <c>Write()</c> methods on the <c>ZipOutputStream</c> class, the caller is

/// responsible for opening the file, reading the bytes from the file, writing

/// those bytes into the <c>ZipOutputStream</c>, setting the attributes on the

/// <c>ZipEntry</c>, and setting the created, last modified, and last accessed

/// timestamps on the zip entry. All of these things are done automatically by a

/// call to <see cref="ZipFile.AddFile(string,string)">ZipFile.AddFile()</see>.

/// For this reason, the <c>ZipOutputStream</c> is generally recommended for use

/// only when your application emits arbitrary data, not necessarily data from a

/// filesystem file, directly into a zip file, and does so using a <c>Stream</c>

/// metaphor.

/// </para>

///

/// <para>

/// Aside from the differences in programming model, there are other

/// differences in capability between the two classes.

/// </para>

///

/// <list type="bullet">

/// <item>

/// <c>ZipFile</c> can be used to read and extract zip files, in addition to

/// creating zip files. <c>ZipOutputStream</c> cannot read zip files. If you want

/// to use a stream to read zip files, check out the <see cref="ZipInputStream"/> class.

/// </item>

///

/// <item>

/// <c>ZipOutputStream</c> does not support the creation of segmented or spanned

/// zip files.

/// </item>

///

/// <item>

/// <c>ZipOutputStream</c> cannot produce a self-extracting archive.

/// </item>

/// </list>

///

/// <para>

/// Be aware that the <c>ZipFile</c> class implements the <see

/// cref="System.IDisposable"/> interface. In order for <c>ZipFile</c> to

/// produce a valid zip file, you use use it within a using clause (<c>Using</c>

/// in VB), or call the <c>Dispose()</c> method explicitly. See the examples

/// for how to employ a using clause.

/// </para>

///

/// </remarks>

[Interop.GuidAttribute("ebc25cf6-9120-4283-b972-0e5520d00005")]

[Interop.ComVisible(true)]

#if !NETCF

[Interop.ClassInterface(Interop.ClassInterfaceType.AutoDispatch)]

#endif

public partial class ZipFile :

System.Collections.IEnumerable,

System.Collections.Generic.IEnumerable<ZipEntry>,

IDisposable

{

#region public properties

/// <summary>

/// Indicates whether to perform a full scan of the zip file when reading it.

/// </summary>

///

/// <remarks>

///

/// <para>

/// You almost never want to use this property.

/// </para>

///

/// <para>

/// When reading a zip file, if this flag is <c>true</c> (<c>True</c> in

/// VB), the entire zip archive will be scanned and searched for entries.

/// For large archives, this can take a very, long time. The much more

/// efficient default behavior is to read the zip directory, which is

/// stored at the end of the zip file. But, in some cases the directory is

/// corrupted and you need to perform a full scan of the zip file to

/// determine the contents of the zip file. This property lets you do

/// that, when necessary.

/// </para>

///

/// <para>

/// This flag is effective only when calling <see

/// cref="Initialize(string)"/>. Normally you would read a ZipFile with the

/// static <see cref="ZipFile.Read(String)">ZipFile.Read</see>

/// method. But you can't set the <c>FullScan</c> property on the

/// <c>ZipFile</c> instance when you use a static factory method like

/// <c>ZipFile.Read</c>.

/// </para>

///

/// </remarks>

///

/// <example>

///

/// This example shows how to read a zip file using the full scan approach,

/// and then save it, thereby producing a corrected zip file.

///

/// <code lang="C#">

/// using (var zip = new ZipFile())

/// {

/// zip.FullScan = true;

/// zip.Initialize(zipFileName);

/// zip.Save(newName);

/// }

/// </code>

///

/// <code lang="VB">

/// Using zip As New ZipFile

/// zip.FullScan = True

/// zip.Initialize(zipFileName)

/// zip.Save(newName)

/// End Using

/// </code>

/// </example>

///

public bool FullScan

{

get;

set;

}

/// <summary>

/// Whether to sort the ZipEntries before saving the file.

/// </summary>

///

/// <remarks>

/// The default is false. If you have a large number of zip entries, the sort

/// alone can consume significant time.

/// </remarks>

///

/// <example>

/// <code lang="C#">

/// using (var zip = new ZipFile())

/// {

/// zip.AddFiles(filesToAdd);

/// zip.SortEntriesBeforeSaving = true;

/// zip.Save(name);

/// }

/// </code>

///

/// <code lang="VB">

/// Using zip As New ZipFile

/// zip.AddFiles(filesToAdd)

/// zip.SortEntriesBeforeSaving = True

/// zip.Save(name)

/// End Using

/// </code>

/// </example>

///

public bool SortEntriesBeforeSaving

{

get;

set;

}

/// <summary>

/// Indicates whether NTFS Reparse Points, like junctions, should be

/// traversed during calls to <c>AddDirectory()</c>.

/// </summary>

///

/// <remarks>

/// By default, calls to AddDirectory() will traverse NTFS reparse

/// points, like mounted volumes, and directory junctions. An example

/// of a junction is the "My Music" directory in Windows Vista. In some

/// cases you may not want DotNetZip to traverse those directories. In

/// that case, set this property to false.

/// </remarks>

///

/// <example>

/// <code lang="C#">

/// using (var zip = new ZipFile())

/// {

/// zip.AddDirectoryWillTraverseReparsePoints = false;

/// zip.AddDirectory(dirToZip,"fodder");

/// zip.Save(zipFileToCreate);

/// }

/// </code>

/// </example>

public bool AddDirectoryWillTraverseReparsePoints { get; set; }

/// <summary>

/// Size of the IO buffer used while saving.

/// </summary>

///

/// <remarks>

///

/// <para>

/// First, let me say that you really don't need to bother with this. It is

/// here to allow for optimizations that you probably won't make! It will work

/// fine if you don't set or get this property at all. Ok?

/// </para>

///

/// <para>

/// Now that we have <em>that</em> out of the way, the fine print: This

/// property affects the size of the buffer that is used for I/O for each

/// entry contained in the zip file. When a file is read in to be compressed,

/// it uses a buffer given by the size here. When you update a zip file, the

/// data for unmodified entries is copied from the first zip file to the

/// other, through a buffer given by the size here.

/// </para>

///

/// <para>

/// Changing the buffer size affects a few things: first, for larger buffer

/// sizes, the memory used by the <c>ZipFile</c>, obviously, will be larger

/// during I/O operations. This may make operations faster for very much

/// larger files. Last, for any given entry, when you use a larger buffer

/// there will be fewer progress events during I/O operations, because there's

/// one progress event generated for each time the buffer is filled and then

/// emptied.

/// </para>

///

/// <para>

/// The default buffer size is 8k. Increasing the buffer size may speed

/// things up as you compress larger files. But there are no hard-and-fast

/// rules here, eh? You won't know til you test it. And there will be a

/// limit where ever larger buffers actually slow things down. So as I said

/// in the beginning, it's probably best if you don't set or get this property

/// at all.

/// </para>

///

/// </remarks>

///

/// <example>

/// This example shows how you might set a large buffer size for efficiency when

/// dealing with zip entries that are larger than 1gb.

/// <code lang="C#">

/// using (ZipFile zip = new ZipFile())

/// {

/// zip.SaveProgress += this.zip1_SaveProgress;

/// zip.AddDirectory(directoryToZip, "");

/// zip.UseZip64WhenSaving = Zip64Option.Always;

/// zip.BufferSize = 65536*8; // 65536 * 8 = 512k

/// zip.Save(ZipFileToCreate);

/// }

/// </code>

/// </example>

public int BufferSize

{

get { return _BufferSize; }

set { _BufferSize = value; }

}

/// <summary>

/// Size of the work buffer to use for the ZLIB codec during compression.

/// </summary>

///

/// <remarks>

/// <para>

/// When doing ZLIB or Deflate compression, the library fills a buffer,

/// then passes it to the compressor for compression. Then the library

/// reads out the compressed bytes. This happens repeatedly until there

/// is no more uncompressed data to compress. This property sets the

/// size of the buffer that will be used for chunk-wise compression. In

/// order for the setting to take effect, your application needs to set

/// this property before calling one of the <c>ZipFile.Save()</c>

/// overloads.

/// </para>

/// <para>

/// Setting this affects the performance and memory efficiency of

/// compression and decompression. For larger files, setting this to a

/// larger size may improve compression performance, but the exact

/// numbers vary depending on available memory, the size of the streams

/// you are compressing, and a bunch of other variables. I don't have

/// good firm recommendations on how to set it. You'll have to test it

/// yourself. Or just leave it alone and accept the default.

/// </para>

/// </remarks>

public int CodecBufferSize

{

get;

set;

}

/// <summary>

/// Indicates whether extracted files should keep their paths as

/// stored in the zip archive.

/// </summary>

///

/// <remarks>

/// <para>

/// This property affects Extraction. It is not used when creating zip

/// archives.

/// </para>

///

/// <para>

/// With this property set to <c>false</c>, the default, extracting entries

/// from a zip file will create files in the filesystem that have the full

/// path associated to the entry within the zip file. With this property set

/// to <c>true</c>, extracting entries from the zip file results in files

/// with no path: the folders are "flattened."

/// </para>

///

/// <para>

/// An example: suppose the zip file contains entries /directory1/file1.txt and

/// /directory2/file2.txt. With <c>FlattenFoldersOnExtract</c> set to false,

/// the files created will be \directory1\file1.txt and \directory2\file2.txt.

/// With the property set to true, the files created are file1.txt and file2.txt.

/// </para>

///

/// </remarks>

public bool FlattenFoldersOnExtract

{

get;

set;

}

/// <summary>

/// The compression strategy to use for all entries.

/// </summary>

///

/// <remarks>

/// Set the Strategy used by the ZLIB-compatible compressor, when

/// compressing entries using the DEFLATE method. Different compression

/// strategies work better on different sorts of data. The strategy

/// parameter can affect the compression ratio and the speed of

/// compression but not the correctness of the compresssion. For more

/// information see <see

/// cref="Ionic.Zlib.CompressionStrategy">Ionic.Zlib.CompressionStrategy</see>.

/// </remarks>

public Ionic.Zlib.CompressionStrategy Strategy

{

get { return _Strategy; }

set { _Strategy = value; }

}

/// <summary>

/// The name of the <c>ZipFile</c>, on disk.

/// </summary>

///

/// <remarks>

///

/// <para>

/// When the <c>ZipFile</c> instance was created by reading an archive using

/// one of the <c>ZipFile.Read</c> methods, this property represents the name

/// of the zip file that was read. When the <c>ZipFile</c> instance was

/// created by using the no-argument constructor, this value is <c>null</c>

/// (<c>Nothing</c> in VB).

/// </para>

///

/// <para>

/// If you use the no-argument constructor, and you then explicitly set this

/// property, when you call <see cref="ZipFile.Save()"/>, this name will

/// specify the name of the zip file created. Doing so is equivalent to

/// calling <see cref="ZipFile.Save(String)"/>. When instantiating a

/// <c>ZipFile</c> by reading from a stream or byte array, the <c>Name</c>

/// property remains <c>null</c>. When saving to a stream, the <c>Name</c>

/// property is implicitly set to <c>null</c>.

/// </para>

/// </remarks>

public string Name

{

get { return _name; }

set { _name = value; }

}

/// <summary>

/// Sets the compression level to be used for entries subsequently added to

/// the zip archive.

/// </summary>

///

/// <remarks>

/// <para>

/// Varying the compression level used on entries can affect the

/// size-vs-speed tradeoff when compression and decompressing data streams

/// or files.

/// </para>

///

/// <para>

/// As with some other properties on the <c>ZipFile</c> class, like <see

/// cref="Password"/>, <see cref="Encryption"/>, and <see

/// cref="ZipErrorAction"/>, setting this property on a <c>ZipFile</c>

/// instance will cause the specified <c>CompressionLevel</c> to be used on all

/// <see cref="ZipEntry"/> items that are subsequently added to the

/// <c>ZipFile</c> instance. If you set this property after you have added

/// items to the <c>ZipFile</c>, but before you have called <c>Save()</c>,

/// those items will not use the specified compression level.

/// </para>

///

/// <para>

/// If you do not set this property, the default compression level is used,

/// which normally gives a good balance of compression efficiency and

/// compression speed. In some tests, using <c>BestCompression</c> can

/// double the time it takes to compress, while delivering just a small

/// increase in compression efficiency. This behavior will vary with the

/// type of data you compress. If you are in doubt, just leave this setting

/// alone, and accept the default.

/// </para>

/// </remarks>

public Ionic.Zlib.CompressionLevel CompressionLevel

{

get;

set;

}

/// <summary>

/// The compression method for the zipfile.

/// </summary>

/// <remarks>

/// <para>

/// By default, the compression method is <c>CompressionMethod.Deflate.</c>

/// </para>

/// </remarks>

/// <seealso cref="Ionic.Zip.CompressionMethod" />

public Ionic.Zip.CompressionMethod CompressionMethod

{

get

{

return _compressionMethod;

}

set

{

_compressionMethod = value;

}

}

/// <summary>

/// A comment attached to the zip archive.

/// </summary>

///

/// <remarks>

///

/// <para>

/// This property is read/write. It allows the application to specify a

/// comment for the <c>ZipFile</c>, or read the comment for the

/// <c>ZipFile</c>. After setting this property, changes are only made

/// permanent when you call a <c>Save()</c> method.

/// </para>

///

/// <para>

/// According to <see

/// href="http://www.pkware.com/documents/casestudies/APPNOTE.TXT">PKWARE's

/// zip specification</see>, the comment is not encrypted, even if there is a

/// password set on the zip file.

/// </para>

///

/// <para>

/// The specification does not describe how to indicate the encoding used

/// on a comment string. Many "compliant" zip tools and libraries use

/// IBM437 as the code page for comments; DotNetZip, too, follows that

/// practice. On the other hand, there are situations where you want a

/// Comment to be encoded with something else, for example using code page

/// 950 "Big-5 Chinese". To fill that need, DotNetZip will encode the

/// comment following the same procedure it follows for encoding

/// filenames: (a) if <see cref="AlternateEncodingUsage"/> is

/// <c>Never</c>, it uses the default encoding (IBM437). (b) if <see

/// cref="AlternateEncodingUsage"/> is <c>Always</c>, it always uses the

/// alternate encoding (<see cref="AlternateEncoding"/>). (c) if <see

/// cref="AlternateEncodingUsage"/> is <c>AsNecessary</c>, it uses the

/// alternate encoding only if the default encoding is not sufficient for

/// encoding the comment - in other words if decoding the result does not

/// produce the original string. This decision is taken at the time of

/// the call to <c>ZipFile.Save()</c>.

/// </para>

///

/// <para>

/// When creating a zip archive using this library, it is possible to change

/// the value of <see cref="AlternateEncoding" /> between each

/// entry you add, and between adding entries and the call to

/// <c>Save()</c>. Don't do this. It will likely result in a zip file that is

/// not readable by any tool or application. For best interoperability, leave

/// <see cref="AlternateEncoding"/> alone, or specify it only

/// once, before adding any entries to the <c>ZipFile</c> instance.

/// </para>

///

/// </remarks>

public string Comment

{

get { return _Comment; }

set

{

_Comment = value;

_contentsChanged = true;

}

}

/// <summary>

/// Specifies whether the Creation, Access, and Modified times for entries

/// added to the zip file will be emitted in &#147;Windows format&#148;

/// when the zip archive is saved.

/// </summary>

///

/// <remarks>

/// <para>

/// An application creating a zip archive can use this flag to explicitly

/// specify that the file times for the entries should or should not be stored

/// in the zip archive in the format used by Windows. By default this flag is

/// <c>true</c>, meaning the Windows-format times are stored in the zip

/// archive.

/// </para>

///

/// <para>

/// When adding an entry from a file or directory, the Creation (<see

/// cref="ZipEntry.CreationTime"/>), Access (<see

/// cref="ZipEntry.AccessedTime"/>), and Modified (<see

/// cref="ZipEntry.ModifiedTime"/>) times for the given entry are

/// automatically set from the filesystem values. When adding an entry from a

/// stream or string, all three values are implicitly set to

/// <c>DateTime.Now</c>. Applications can also explicitly set those times by

/// calling <see cref="ZipEntry.SetEntryTimes(DateTime, DateTime,

/// DateTime)"/>.

/// </para>

///

/// <para>

/// <see

/// href="http://www.pkware.com/documents/casestudies/APPNOTE.TXT">PKWARE's

/// zip specification</see> describes multiple ways to format these times in a

/// zip file. One is the format Windows applications normally use: 100ns ticks

/// since January 1, 1601 UTC. The other is a format Unix applications typically

/// use: seconds since January 1, 1970 UTC. Each format can be stored in an

/// "extra field" in the zip entry when saving the zip archive. The former

/// uses an extra field with a Header Id of 0x000A, while the latter uses a

/// header ID of 0x5455, although you probably don't need to know that.

/// </para>

///

/// <para>

/// Not all tools and libraries can interpret these fields. Windows

/// compressed folders is one that can read the Windows Format timestamps,

/// while I believe <see href="http://www.info-zip.org/">the Infozip

/// tools</see> can read the Unix format timestamps. Some tools and libraries

/// may be able to read only one or the other. DotNetZip can read or write

/// times in either or both formats.

/// </para>

///

/// <para>

/// The times stored are taken from <see cref="ZipEntry.ModifiedTime"/>, <see

/// cref="ZipEntry.AccessedTime"/>, and <see cref="ZipEntry.CreationTime"/>.

/// </para>

///

/// <para>

/// The value set here applies to all entries subsequently added to the

/// <c>ZipFile</c>.

/// </para>

///

/// <para>

/// This property is not mutually exclusive of the <see

/// cref="EmitTimesInUnixFormatWhenSaving" /> property. It is possible and

/// legal and valid to produce a zip file that contains timestamps encoded in

/// the Unix format as well as in the Windows format, in addition to the <see

/// cref="ZipEntry.LastModified">LastModified</see> time attached to each

/// entry in the archive, a time that is always stored in "DOS format". And,

/// notwithstanding the names PKWare uses for these time formats, any of them

/// can be read and written by any computer, on any operating system. But,

/// there are no guarantees that a program running on Mac or Linux will

/// gracefully handle a zip file with "Windows" formatted times, or that an

/// application that does not use DotNetZip but runs on Windows will be able to

/// handle file times in Unix format.

/// </para>

///

/// <para>

/// When in doubt, test. Sorry, I haven't got a complete list of tools and

/// which sort of timestamps they can use and will tolerate. If you get any

/// good information and would like to pass it on, please do so and I will

/// include that information in this documentation.

/// </para>

/// </remarks>

///

/// <example>

/// This example shows how to save a zip file that contains file timestamps

/// in a format normally used by Unix.

/// <code lang="C#">

/// using (var zip = new ZipFile())

/// {

/// // produce a zip file the Mac will like

/// zip.EmitTimesInWindowsFormatWhenSaving = false;

/// zip.EmitTimesInUnixFormatWhenSaving = true;

/// zip.AddDirectory(directoryToZip, "files");

/// zip.Save(outputFile);

/// }

/// </code>

///

/// <code lang="VB">

/// Using zip As New ZipFile

/// '' produce a zip file the Mac will like

/// zip.EmitTimesInWindowsFormatWhenSaving = False

/// zip.EmitTimesInUnixFormatWhenSaving = True

/// zip.AddDirectory(directoryToZip, "files")

/// zip.Save(outputFile)

/// End Using

/// </code>

/// </example>

///

/// <seealso cref="ZipEntry.EmitTimesInWindowsFormatWhenSaving" />

/// <seealso cref="EmitTimesInUnixFormatWhenSaving" />

public bool EmitTimesInWindowsFormatWhenSaving

{

get

{

return _emitNtfsTimes;

}

set

{

_emitNtfsTimes = value;

}

}

/// <summary>

/// Specifies whether the Creation, Access, and Modified times

/// for entries added to the zip file will be emitted in "Unix(tm)

/// format" when the zip archive is saved.

/// </summary>

///

/// <remarks>

/// <para>

/// An application creating a zip archive can use this flag to explicitly

/// specify that the file times for the entries should or should not be stored

/// in the zip archive in the format used by Unix. By default this flag is

/// <c>false</c>, meaning the Unix-format times are not stored in the zip

/// archive.

/// </para>

///

/// <para>

/// When adding an entry from a file or directory, the Creation (<see

/// cref="ZipEntry.CreationTime"/>), Access (<see

/// cref="ZipEntry.AccessedTime"/>), and Modified (<see

/// cref="ZipEntry.ModifiedTime"/>) times for the given entry are

/// automatically set from the filesystem values. When adding an entry from a

/// stream or string, all three values are implicitly set to DateTime.Now.

/// Applications can also explicitly set those times by calling <see

/// cref="ZipEntry.SetEntryTimes(DateTime, DateTime, DateTime)"/>.

/// </para>

///

/// <para>

/// <see

/// href="http://www.pkware.com/documents/casestudies/APPNOTE.TXT">PKWARE's

/// zip specification</see> describes multiple ways to format these times in a

/// zip file. One is the format Windows applications normally use: 100ns ticks

/// since January 1, 1601 UTC. The other is a format Unix applications

/// typically use: seconds since January 1, 1970 UTC. Each format can be

/// stored in an "extra field" in the zip entry when saving the zip

/// archive. The former uses an extra field with a Header Id of 0x000A, while

/// the latter uses a header ID of 0x5455, although you probably don't need to

/// know that.

/// </para>

///

/// <para>

/// Not all tools and libraries can interpret these fields. Windows

/// compressed folders is one that can read the Windows Format timestamps,

/// while I believe the <see href="http://www.info-zip.org/">Infozip</see>

/// tools can read the Unix format timestamps. Some tools and libraries may be

/// able to read only one or the other. DotNetZip can read or write times in

/// either or both formats.

/// </para>

///

/// <para>

/// The times stored are taken from <see cref="ZipEntry.ModifiedTime"/>, <see

/// cref="ZipEntry.AccessedTime"/>, and <see cref="ZipEntry.CreationTime"/>.

/// </para>

///

/// <para>

/// This property is not mutually exclusive of the <see

/// cref="EmitTimesInWindowsFormatWhenSaving" /> property. It is possible and

/// legal and valid to produce a zip file that contains timestamps encoded in

/// the Unix format as well as in the Windows format, in addition to the <see

/// cref="ZipEntry.LastModified">LastModified</see> time attached to each

/// entry in the zip archive, a time that is always stored in "DOS

/// format". And, notwithstanding the names PKWare uses for these time

/// formats, any of them can be read and written by any computer, on any

/// operating system. But, there are no guarantees that a program running on

/// Mac or Linux will gracefully handle a zip file with "Windows" formatted

/// times, or that an application that does not use DotNetZip but runs on

/// Windows will be able to handle file times in Unix format.

/// </para>

///

/// <para>

/// When in doubt, test. Sorry, I haven't got a complete list of tools and

/// which sort of timestamps they can use and will tolerate. If you get any

/// good information and would like to pass it on, please do so and I will

/// include that information in this documentation.

/// </para>

/// </remarks>

///

/// <seealso cref="ZipEntry.EmitTimesInUnixFormatWhenSaving" />

/// <seealso cref="EmitTimesInWindowsFormatWhenSaving" />

public bool EmitTimesInUnixFormatWhenSaving

{

get

{

return _emitUnixTimes;

}

set

{

_emitUnixTimes = value;

}

}

/// <summary>

/// Indicates whether verbose output is sent to the <see

/// cref="StatusMessageTextWriter"/> during <c>AddXxx()</c> and

/// <c>ReadXxx()</c> operations.

/// </summary>

///

/// <remarks>

/// This is a <em>synthetic</em> property. It returns true if the <see

/// cref="StatusMessageTextWriter"/> is non-null.

/// </remarks>

internal bool Verbose

{

get { return (_StatusMessageTextWriter != null); }

}

/// <summary>

/// Returns true if an entry by the given name exists in the ZipFile.

/// </summary>

///

/// <param name='name'>the name of the entry to find</param>

/// <returns>true if an entry with the given name exists; otherwise false.

/// </returns>

public bool ContainsEntry(string name)

{

// workitem 12534

return _entries.ContainsKey(SharedUtilities.NormalizePathForUseInZipFile(name));

}

/// <summary>

/// Indicates whether to perform case-sensitive matching on the filename when

/// retrieving entries in the zipfile via the string-based indexer.

/// </summary>

///

/// <remarks>

/// The default value is <c>false</c>, which means don't do case-sensitive

/// matching. In other words, retrieving zip["ReadMe.Txt"] is the same as

/// zip["readme.txt"]. It really makes sense to set this to <c>true</c> only

/// if you are not running on Windows, which has case-insensitive

/// filenames. But since this library is not built for non-Windows platforms,

/// in most cases you should just leave this property alone.

/// </remarks>

public bool CaseSensitiveRetrieval

{

get

{

return _CaseSensitiveRetrieval;

}

set

{

// workitem 9868

if (value != _CaseSensitiveRetrieval)

{

_CaseSensitiveRetrieval = value;

_initEntriesDictionary();

}

}

}

/// <summary>

/// Indicates whether to encode entry filenames and entry comments using Unicode

/// (UTF-8).

/// </summary>

///

/// <remarks>

/// <para>

/// <see href="http://www.pkware.com/documents/casestudies/APPNOTE.TXT">The

/// PKWare zip specification</see> provides for encoding file names and file

/// comments in either the IBM437 code page, or in UTF-8. This flag selects

/// the encoding according to that specification. By default, this flag is

/// false, and filenames and comments are encoded into the zip file in the

/// IBM437 codepage. Setting this flag to true will specify that filenames

/// and comments that cannot be encoded with IBM437 will be encoded with

/// UTF-8.

/// </para>

///

/// <para>

/// Zip files created with strict adherence to the PKWare specification with

/// respect to UTF-8 encoding can contain entries with filenames containing

/// any combination of Unicode characters, including the full range of

/// characters from Chinese, Latin, Hebrew, Greek, Cyrillic, and many other

/// alphabets. However, because at this time, the UTF-8 portion of the PKWare

/// specification is not broadly supported by other zip libraries and

/// utilities, such zip files may not be readable by your favorite zip tool or

/// archiver. In other words, interoperability will decrease if you set this

/// flag to true.

/// </para>

///

/// <para>

/// In particular, Zip files created with strict adherence to the PKWare

/// specification with respect to UTF-8 encoding will not work well with

/// Explorer in Windows XP or Windows Vista, because Windows compressed

/// folders, as far as I know, do not support UTF-8 in zip files. Vista can

/// read the zip files, but shows the filenames incorrectly. Unpacking from

/// Windows Vista Explorer will result in filenames that have rubbish

/// characters in place of the high-order UTF-8 bytes.

/// </para>

///

/// <para>

/// Also, zip files that use UTF-8 encoding will not work well with Java

/// applications that use the java.util.zip classes, as of v5.0 of the Java

/// runtime. The Java runtime does not correctly implement the PKWare

/// specification in this regard.

/// </para>

///

/// <para>

/// As a result, we have the unfortunate situation that "correct" behavior by

/// the DotNetZip library with regard to Unicode encoding of filenames during

/// zip creation will result in zip files that are readable by strictly

/// compliant and current tools (for example the most recent release of the

/// commercial WinZip tool); but these zip files will not be readable by

/// various other tools or libraries, including Windows Explorer.

/// </para>

///

/// <para>

/// The DotNetZip library can read and write zip files with UTF8-encoded

/// entries, according to the PKware spec. If you use DotNetZip for both

/// creating and reading the zip file, and you use UTF-8, there will be no

/// loss of information in the filenames. For example, using a self-extractor

/// created by this library will allow you to unpack files correctly with no

/// loss of information in the filenames.

/// </para>

///

/// <para>

/// If you do not set this flag, it will remain false. If this flag is false,

/// your <c>ZipFile</c> will encode all filenames and comments using the

/// IBM437 codepage. This can cause "loss of information" on some filenames,

/// but the resulting zipfile will be more interoperable with other

/// utilities. As an example of the loss of information, diacritics can be

/// lost. The o-tilde character will be down-coded to plain o. The c with a

/// cedilla (Unicode 0xE7) used in Portugese will be downcoded to a c.

/// Likewise, the O-stroke character (Unicode 248), used in Danish and

/// Norwegian, will be down-coded to plain o. Chinese characters cannot be

/// represented in codepage IBM437; when using the default encoding, Chinese

/// characters in filenames will be represented as ?. These are all examples

/// of "information loss".

/// </para>

///

/// <para>

/// The loss of information associated to the use of the IBM437 encoding is

/// inconvenient, and can also lead to runtime errors. For example, using

/// IBM437, any sequence of 4 Chinese characters will be encoded as ????. If

/// your application creates a <c>ZipFile</c>, then adds two files, each with

/// names of four Chinese characters each, this will result in a duplicate

/// filename exception. In the case where you add a single file with a name

/// containing four Chinese characters, calling Extract() on the entry that

/// has question marks in the filename will result in an exception, because

/// the question mark is not legal for use within filenames on Windows. These

/// are just a few examples of the problems associated to loss of information.

/// </para>

///

/// <para>

/// This flag is independent of the encoding of the content within the entries

/// in the zip file. Think of the zip file as a container - it supports an

/// encoding. Within the container are other "containers" - the file entries

/// themselves. The encoding within those entries is independent of the

/// encoding of the zip archive container for those entries.

/// </para>

///

/// <para>

/// Rather than specify the encoding in a binary fashion using this flag, an

/// application can specify an arbitrary encoding via the <see

/// cref="ProvisionalAlternateEncoding"/> property. Setting the encoding

/// explicitly when creating zip archives will result in non-compliant zip

/// files that, curiously, are fairly interoperable. The challenge is, the

/// PKWare specification does not provide for a way to specify that an entry

/// in a zip archive uses a code page that is neither IBM437 nor UTF-8.

/// Therefore if you set the encoding explicitly when creating a zip archive,

/// you must take care upon reading the zip archive to use the same code page.

/// If you get it wrong, the behavior is undefined and may result in incorrect

/// filenames, exceptions, stomach upset, hair loss, and acne.

/// </para>

/// </remarks>

/// <seealso cref="ProvisionalAlternateEncoding"/>

[Obsolete("Beginning with v1.9.1.6 of DotNetZip, this property is obsolete. It will be removed in a future version of the library. Your applications should use AlternateEncoding and AlternateEncodingUsage instead.")]

public bool UseUnicodeAsNecessary

{

get

{

return (_alternateEncoding == System.Text.Encoding.GetEncoding("UTF-8")) &&

(_alternateEncodingUsage == ZipOption.AsNecessary);

}

set

{

if (value)

{

_alternateEncoding = System.Text.Encoding.GetEncoding("UTF-8");

_alternateEncodingUsage = ZipOption.AsNecessary;

}

else

{

_alternateEncoding = Ionic.Zip.ZipFile.DefaultEncoding;

_alternateEncodingUsage = ZipOption.Never;

}

}

}

/// <summary>

/// Specify whether to use ZIP64 extensions when saving a zip archive.

/// </summary>

///

/// <remarks>

///

/// <para>

/// When creating a zip file, the default value for the property is <see

/// cref="Zip64Option.Never"/>. <see cref="Zip64Option.AsNecessary"/> is

/// safest, in the sense that you will not get an Exception if a pre-ZIP64

/// limit is exceeded.

/// </para>

///

/// <para>

/// You may set the property at any time before calling Save().

/// </para>

///

/// <para>

/// When reading a zip file via the <c>Zipfile.Read()</c> method, DotNetZip