-
Notifications
You must be signed in to change notification settings - Fork 0
/
Ionic.Zip.XML
14326 lines (14119 loc) · 733 KB
/
Ionic.Zip.XML
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0"?>
<doc>
<assembly>
<name>Ionic.Zip</name>
</assembly>
<members>
<member name="T:Ionic.Zip.ZipEntry">
<summary>
Represents a single entry in a ZipFile. Typically, applications get a ZipEntry
by enumerating the entries within a ZipFile, or by adding an entry to a ZipFile.
</summary>
</member>
<member name="M:Ionic.Zip.ZipEntry.ReadEntry(Ionic.Zip.ZipContainer,System.Boolean)">
<summary>
Reads one <c>ZipEntry</c> from the given stream. If the entry is encrypted, we don't
decrypt at this point. We also do not decompress. Mostly we read metadata.
</summary>
<param name="zc">the ZipContainer this entry belongs to.</param>
<param name="first">true of this is the first entry being read from the stream.</param>
<returns>the <c>ZipEntry</c> read from the stream.</returns>
</member>
<member name="M:Ionic.Zip.ZipEntry.ReadDirEntry(Ionic.Zip.ZipFile)">
<summary>
Reads one entry from the zip directory structure in the zip file.
</summary>
<param name="zf">
The zipfile for which a directory entry will be read. From this param, the
method gets the ReadStream and the expected text encoding
(ProvisionalAlternateEncoding) which is used if the entry is not marked
UTF-8.
</param>
<returns>the entry read from the archive.</returns>
</member>
<member name="M:Ionic.Zip.ZipEntry.IsNotValidZipDirEntrySig(System.Int32)">
<summary>
Returns true if the passed-in value is a valid signature for a ZipDirEntry.
</summary>
<param name="signature">the candidate 4-byte signature value.</param>
<returns>true, if the signature is valid according to the PKWare spec.</returns>
</member>
<member name="M:Ionic.Zip.ZipEntry.PrepSourceStream">
<summary>
Stores the position of the entry source stream, or, if the position is
already stored, seeks to that position.
</summary>
<remarks>
<para>
This method is called in prep for reading the source stream. If PKZIP
encryption is used, then we need to calc the CRC32 before doing the
encryption, because the CRC is used in the 12th byte of the PKZIP
encryption header. So, we need to be able to seek backward in the source
when saving the ZipEntry. This method is called from the place that
calculates the CRC, and also from the method that does the encryption of
the file data.
</para>
<para>
The first time through, this method sets the _sourceStreamOriginalPosition
field. Subsequent calls to this method seek to that position.
</para>
</remarks>
</member>
<member name="M:Ionic.Zip.ZipEntry.CopyMetaData(Ionic.Zip.ZipEntry)">
<summary>
Copy metadata that may have been changed by the app. We do this when
resetting the zipFile instance. If the app calls Save() on a ZipFile, then
tries to party on that file some more, we may need to Reset() it , which
means re-reading the entries and then copying the metadata. I think.
</summary>
</member>
<member name="M:Ionic.Zip.ZipEntry.SetInputAndFigureFileLength(System.IO.Stream@)">
<summary>
Set the input stream and get its length, if possible. The
length is used for progress updates, AND, to allow an
optimization in case of a stream/file of zero length. In
that case we skip the Encrypt and DeflateStream.
</summary>
</member>
<member name="M:Ionic.Zip.ZipEntry.#ctor">
<summary>
Default constructor.
</summary>
<remarks>
Applications should never need to call this directly. It is exposed to
support COM Automation environments.
</remarks>
</member>
<member name="M:Ionic.Zip.ZipEntry.SetEntryTimes(System.DateTime,System.DateTime,System.DateTime)">
<summary>
Sets the NTFS Creation, Access, and Modified times for the given entry.
</summary>
<remarks>
<para>
When adding an entry from a file or directory, the Creation, Access, and
Modified times for the given entry are automatically set from the
filesystem values. When adding an entry from a stream or string, the
values are implicitly set to DateTime.Now. The application may wish to
set these values to some arbitrary value, before saving the archive, and
can do so using the various setters. If you want to set all of the times,
this method is more efficient.
</para>
<para>
The values you set here will be retrievable with the <see cref="P:Ionic.Zip.ZipEntry.ModifiedTime" />, <see cref="P:Ionic.Zip.ZipEntry.CreationTime" /> and <see cref="P:Ionic.Zip.ZipEntry.AccessedTime" /> properties.
</para>
<para>
When this method is called, if both <see cref="P:Ionic.Zip.ZipEntry.EmitTimesInWindowsFormatWhenSaving" /> and <see cref="P:Ionic.Zip.ZipEntry.EmitTimesInUnixFormatWhenSaving" /> are false, then the
<c>EmitTimesInWindowsFormatWhenSaving</c> flag is automatically set.
</para>
<para>
DateTime values provided here without a DateTimeKind are assumed to be Local Time.
</para>
</remarks>
<param name="created">the creation time of the entry.</param>
<param name="accessed">the last access time of the entry.</param>
<param name="modified">the last modified time of the entry.</param>
<seealso cref="P:Ionic.Zip.ZipEntry.EmitTimesInWindowsFormatWhenSaving" />
<seealso cref="P:Ionic.Zip.ZipEntry.EmitTimesInUnixFormatWhenSaving" />
<seealso cref="P:Ionic.Zip.ZipEntry.AccessedTime" />
<seealso cref="P:Ionic.Zip.ZipEntry.CreationTime" />
<seealso cref="P:Ionic.Zip.ZipEntry.ModifiedTime" />
</member>
<member name="M:Ionic.Zip.ZipEntry.ToString">
<summary>Provides a string representation of the instance.</summary>
<returns>a string representation of the instance.</returns>
</member>
<member name="M:Ionic.Zip.ZipEntry.Extract">
<summary>
Extract the entry to the filesystem, starting at the current working directory.
</summary>
<overloads>
This method has a bunch of overloads! One of them is sure to be
the right one for you... If you don't like these, check out the
<c>ExtractWithPassword()</c> methods.
</overloads>
<seealso cref="P:Ionic.Zip.ZipEntry.ExtractExistingFile" />
<seealso cref="M:Ionic.Zip.ZipEntry.Extract(Ionic.Zip.ExtractExistingFileAction)" />
<remarks>
<para> This method extracts an entry from a zip file into the current working
directory. The path of the entry as extracted is the full path as specified in
the zip archive, relative to the current working directory. After the file is
extracted successfully, the file attributes and timestamps are set. </para>
<para>
The action taken when extraction an entry would overwrite an existing file
is determined by the <see cref="P:Ionic.Zip.ZipEntry.ExtractExistingFile" /> property.
</para>
<para>
See the remarks the <see cref="P:Ionic.Zip.ZipEntry.LastModified" /> property, for some details
about how the last modified time of the file is set after extraction.
</para>
</remarks>
</member>
<member name="M:Ionic.Zip.ZipEntry.Extract(Ionic.Zip.ExtractExistingFileAction)">
<summary>
Extract the entry to a file in the filesystem, using the specified behavior
when extraction would overwrite an existing file.
</summary>
<remarks>
<para>
See the remarks on the <see cref="P:Ionic.Zip.ZipEntry.LastModified" /> property, for some details
about how the last modified time of the file is set after extraction.
</para>
</remarks>
<param name="extractExistingFile">The action to take if extraction would
overwrite an existing file.</param>
</member>
<member name="M:Ionic.Zip.ZipEntry.Extract(System.IO.Stream)">
<summary>
Extracts the entry to the specified stream.
</summary>
<remarks>
<para>
The caller can specify any write-able stream, for example <see cref="M:System.Console.OpenStandardOutput" />, a <see cref="T:System.IO.FileStream" />, a <see cref="T:System.IO.MemoryStream" />, or
ASP.NET's <c>Response.OutputStream</c>.
The content will be decrypted and decompressed as necessary. If the entry is
encrypted and no password is provided, this method will throw.
</para>
</remarks>
<param name="stream">the stream to which the entry should be extracted. </param>
</member>
<member name="M:Ionic.Zip.ZipEntry.Extract(System.String)">
<summary>
Extract the entry to the filesystem, starting at the specified base directory.
</summary>
<param name="baseDirectory">the pathname of the base directory</param>
<seealso cref="P:Ionic.Zip.ZipEntry.ExtractExistingFile" />
<seealso cref="M:Ionic.Zip.ZipEntry.Extract(System.String,Ionic.Zip.ExtractExistingFileAction)" />
<example>
This example extracts only the entries in a zip file that are .txt files,
into a directory called "textfiles".
<code lang="C#">
using (ZipFile zip = ZipFile.Read("PackedDocuments.zip"))
{
foreach (string s1 in zip.EntryFilenames)
{
if (s1.EndsWith(".txt"))
{
zip[s1].Extract("textfiles");
}
}
}
</code><code lang="VB">
Using zip As ZipFile = ZipFile.Read("PackedDocuments.zip")
Dim s1 As String
For Each s1 In zip.EntryFilenames
If s1.EndsWith(".txt") Then
zip(s1).Extract("textfiles")
End If
Next
End Using
</code></example>
<remarks>
<para> Using this method, existing entries in the filesystem will not be
overwritten. If you would like to force the overwrite of existing files, see the
<see cref="P:Ionic.Zip.ZipEntry.ExtractExistingFile" /> property, or call <see cref="M:Ionic.Zip.ZipEntry.Extract(System.String,Ionic.Zip.ExtractExistingFileAction)" />. </para>
<para>
See the remarks on the <see cref="P:Ionic.Zip.ZipEntry.LastModified" /> property, for some details
about how the last modified time of the created file is set.
</para>
</remarks>
</member>
<member name="M:Ionic.Zip.ZipEntry.Extract(System.String,Ionic.Zip.ExtractExistingFileAction)">
<summary>
Extract the entry to the filesystem, starting at the specified base directory, and
using the specified behavior when extraction would overwrite an existing file.
</summary>
<remarks>
<para>
See the remarks on the <see cref="P:Ionic.Zip.ZipEntry.LastModified" /> property, for some details
about how the last modified time of the created file is set.
</para>
</remarks>
<example>
<code lang="C#">
String sZipPath = "Airborne.zip";
String sFilePath = "Readme.txt";
String sRootFolder = "Digado";
using (ZipFile zip = ZipFile.Read(sZipPath))
{
if (zip.EntryFileNames.Contains(sFilePath))
{
// use the string indexer on the zip file
zip[sFileName].Extract(sRootFolder,
ExtractExistingFileAction.OverwriteSilently);
}
}
</code>
<code lang="VB">
Dim sZipPath as String = "Airborne.zip"
Dim sFilePath As String = "Readme.txt"
Dim sRootFolder As String = "Digado"
Using zip As ZipFile = ZipFile.Read(sZipPath)
If zip.EntryFileNames.Contains(sFilePath)
' use the string indexer on the zip file
zip(sFilePath).Extract(sRootFolder, _
ExtractExistingFileAction.OverwriteSilently)
End If
End Using
</code>
</example>
<param name="baseDirectory">the pathname of the base directory</param>
<param name="extractExistingFile">
The action to take if extraction would overwrite an existing file.
</param>
</member>
<member name="M:Ionic.Zip.ZipEntry.ExtractWithPassword(System.String)">
<summary>
Extract the entry to the filesystem, using the current working directory
and the specified password.
</summary>
<overloads>
This method has a bunch of overloads! One of them is sure to be
the right one for you...
</overloads>
<seealso cref="P:Ionic.Zip.ZipEntry.ExtractExistingFile" />
<seealso cref="M:Ionic.Zip.ZipEntry.ExtractWithPassword(Ionic.Zip.ExtractExistingFileAction,System.String)" />
<remarks>
<para> Existing entries in the filesystem will not be overwritten. If you would
like to force the overwrite of existing files, see the <see cref="P:Ionic.Zip.ZipEntry.ExtractExistingFile" />property, or call <see cref="M:Ionic.Zip.ZipEntry.ExtractWithPassword(Ionic.Zip.ExtractExistingFileAction,System.String)" />.</para>
<para>
See the remarks on the <see cref="P:Ionic.Zip.ZipEntry.LastModified" /> property for some details
about how the "last modified" time of the created file is set.
</para>
</remarks>
<example>
In this example, entries that use encryption are extracted using a particular password.
<code>
using (var zip = ZipFile.Read(FilePath))
{
foreach (ZipEntry e in zip)
{
if (e.UsesEncryption)
e.ExtractWithPassword("Secret!");
else
e.Extract();
}
}
</code><code lang="VB">
Using zip As ZipFile = ZipFile.Read(FilePath)
Dim e As ZipEntry
For Each e In zip
If (e.UsesEncryption)
e.ExtractWithPassword("Secret!")
Else
e.Extract
End If
Next
End Using
</code></example>
<param name="password">The Password to use for decrypting the entry.</param>
</member>
<member name="M:Ionic.Zip.ZipEntry.ExtractWithPassword(System.String,System.String)">
<summary>
Extract the entry to the filesystem, starting at the specified base directory,
and using the specified password.
</summary>
<seealso cref="P:Ionic.Zip.ZipEntry.ExtractExistingFile" />
<seealso cref="M:Ionic.Zip.ZipEntry.ExtractWithPassword(System.String,Ionic.Zip.ExtractExistingFileAction,System.String)" />
<remarks>
<para> Existing entries in the filesystem will not be overwritten. If you would
like to force the overwrite of existing files, see the <see cref="P:Ionic.Zip.ZipEntry.ExtractExistingFile" />property, or call <see cref="M:Ionic.Zip.ZipEntry.ExtractWithPassword(Ionic.Zip.ExtractExistingFileAction,System.String)" />.</para>
<para>
See the remarks on the <see cref="P:Ionic.Zip.ZipEntry.LastModified" /> property, for some details
about how the last modified time of the created file is set.
</para>
</remarks>
<param name="baseDirectory">The pathname of the base directory.</param>
<param name="password">The Password to use for decrypting the entry.</param>
</member>
<member name="M:Ionic.Zip.ZipEntry.ExtractWithPassword(Ionic.Zip.ExtractExistingFileAction,System.String)">
<summary>
Extract the entry to a file in the filesystem, relative to the current directory,
using the specified behavior when extraction would overwrite an existing file.
</summary>
<remarks>
<para>
See the remarks on the <see cref="P:Ionic.Zip.ZipEntry.LastModified" /> property, for some details
about how the last modified time of the created file is set.
</para>
</remarks>
<param name="password">The Password to use for decrypting the entry.</param>
<param name="extractExistingFile">
The action to take if extraction would overwrite an existing file.
</param>
</member>
<member name="M:Ionic.Zip.ZipEntry.ExtractWithPassword(System.String,Ionic.Zip.ExtractExistingFileAction,System.String)">
<summary>
Extract the entry to the filesystem, starting at the specified base directory, and
using the specified behavior when extraction would overwrite an existing file.
</summary>
<remarks>
See the remarks on the <see cref="P:Ionic.Zip.ZipEntry.LastModified" /> property, for some details
about how the last modified time of the created file is set.
</remarks>
<param name="baseDirectory">the pathname of the base directory</param>
<param name="extractExistingFile">The action to take if extraction would
overwrite an existing file.</param>
<param name="password">The Password to use for decrypting the entry.</param>
</member>
<member name="M:Ionic.Zip.ZipEntry.ExtractWithPassword(System.IO.Stream,System.String)">
<summary>
Extracts the entry to the specified stream, using the specified Password.
For example, the caller could extract to Console.Out, or to a MemoryStream.
</summary>
<remarks>
See the remarks on the <see cref="P:Ionic.Zip.ZipEntry.LastModified" /> property, for some details
about how the last modified time of the created file is set.
</remarks>
<param name="stream">the stream to which the entry should be extracted. </param>
<param name="password">The password to use for decrypting the entry.</param>
</member>
<member name="M:Ionic.Zip.ZipEntry.OpenReader">
<summary>
Opens the backing stream for the zip entry in the archive, for reading.
</summary>
<remarks>
<para>
DotNetZip offers a variety of ways to extract entries from a zip file. This
method allows an application to extract and entry by reading a Stream.
</para>
<para>
The return value is a <see cref="T:Ionic.Zlib.CrcCalculatorStream" />. Use it
as you would any stream for reading. The data you get by calling <see cref="M:System.IO.Stream.Read(System.Byte[],System.Int32,System.Int32)" /> on that stream will be decrypted and
decompressed.
</para>
<para>
CrcCalculatorStream adds one additional feature: it keeps a CRC32 checksum
on the bytes of the stream as it is read. The CRC value is available in the
<see cref="P:Ionic.Zlib.CrcCalculatorStream.Crc" /> property on the
<c>CrcCalculatorStream</c>. When the read is complete, this CRC
<em>should</em> be checked against the <see cref="P:Ionic.Zip.ZipEntry.Crc" /> property
on the <c>ZipEntry</c> to validate the content of the ZipEntry. You don't
have to validate the entry using the CRC, but you should. Check the example
for how to do this.
</para>
<para>
If the entry is protected with a password, then you need to provide a
password prior to calling <see cref="M:Ionic.Zip.ZipEntry.OpenReader" />, either by setting the
<see cref="P:Ionic.Zip.ZipEntry.Password" /> property on the entry, or the <see cref="P:Ionic.Zip.ZipFile.Password" /> property on the <c>ZipFile</c> itself. Or, you can
use <see cref="M:Ionic.Zip.ZipEntry.OpenReader(System.String)" />, the overload of OpenReader that
accepts a password parameter.
</para>
<para>
If you want to extract entry data into a stream that is already opened, like
a <see cref="T:System.IO.FileStream" />, consider the <see cref="M:Ionic.Zip.ZipEntry.Extract(System.IO.Stream)" /> method.
</para>
</remarks>
<example>
This example shows how to open a zip archive, then read in a named entry via
a stream. After the read loop is complete, the code compares the calculated
during the read loop with the expected CRC on the <c>ZipEntry</c>, to verify
the extraction.
<code>
using (ZipFile zip = new ZipFile(ZipFileToRead))
{
ZipEntry e1= zip["Elevation.mp3"];
using (Ionic.Zlib.CrcCalculatorStream s = e1.OpenReader())
{
byte[] buffer = new byte[4096];
int n, totalBytesRead= 0;
do {
n = s.Read(buffer,0, buffer.Length);
totalBytesRead+=n;
} while (n>0);
if (s.Crc32 != e1.Crc32)
throw new Exception(string.Format("The Zip Entry failed the CRC Check. (0x{0:X8}!=0x{1:X8})", s.Crc32, e1.Crc32));
if (totalBytesRead != e1.UncompressedSize)
throw new Exception(string.Format("We read an unexpected number of bytes. ({0}!={1})", totalBytesRead, e1.UncompressedSize));
}
}
</code><code lang="VB">
Using zip As New ZipFile(ZipFileToRead)
Dim e1 As ZipEntry = zip.Item("Elevation.mp3")
Using s As Ionic.Zlib.CrcCalculatorStream = e1.OpenReader
Dim n As Integer
Dim buffer As Byte() = New Byte(4096) {}
Dim totalBytesRead As Integer = 0
Do
n = s.Read(buffer, 0, buffer.Length)
totalBytesRead = (totalBytesRead + n)
Loop While (n > 0)
If (s.Crc32 <> e1.Crc32) Then
Throw New Exception(String.Format("The Zip Entry failed the CRC Check. (0x{0:X8}!=0x{1:X8})", s.Crc32, e1.Crc32))
End If
If (totalBytesRead <> e1.UncompressedSize) Then
Throw New Exception(String.Format("We read an unexpected number of bytes. ({0}!={1})", totalBytesRead, e1.UncompressedSize))
End If
End Using
End Using
</code></example>
<seealso cref="M:Ionic.Zip.ZipEntry.Extract(System.IO.Stream)" />
<returns>The Stream for reading.</returns>
</member>
<member name="M:Ionic.Zip.ZipEntry.OpenReader(System.String)">
<summary>
Opens the backing stream for an encrypted zip entry in the archive, for reading.
</summary>
<remarks>
<para>
See the documentation on the <see cref="M:Ionic.Zip.ZipEntry.OpenReader" /> method for full
details. This overload allows the application to specify a password for the
<c>ZipEntry</c> to be read.
</para>
</remarks>
<param name="password">The password to use for decrypting the entry.</param>
<returns>The Stream for reading.</returns>
</member>
<member name="M:Ionic.Zip.ZipEntry.ValidateOutput(System.String,System.IO.Stream,System.String@)">
<summary>
Validates that the args are consistent.
</summary>
<remarks>
Only one of {baseDir, outStream} can be non-null.
If baseDir is non-null, then the outputFile is created.
</remarks>
</member>
<member name="P:Ionic.Zip.ZipEntry.AttributesIndicateDirectory">
<summary>
True if the referenced entry is a directory.
</summary>
</member>
<member name="P:Ionic.Zip.ZipEntry.Info">
<summary>
Provides a human-readable string with information about the ZipEntry.
</summary>
</member>
<member name="P:Ionic.Zip.ZipEntry.LastModified">
<summary>
The time and date at which the file indicated by the <c>ZipEntry</c> was
last modified.
</summary>
<remarks>
<para>
The DotNetZip library sets the LastModified value for an entry, equal to
the Last Modified time of the file in the filesystem. If an entry is
added from a stream, the library uses <c>System.DateTime.Now</c> for this
value, for the given entry.
</para>
<para>
This property allows the application to retrieve and possibly set the
LastModified value on an entry, to an arbitrary value. <see cref="T:System.DateTime" /> values with a <see cref="T:System.DateTimeKind" />
setting of <c>DateTimeKind.Unspecified</c> are taken to be expressed as
<c>DateTimeKind.Local</c>.
</para>
<para>
Be aware that because of the way <see href="http://www.pkware.com/documents/casestudies/APPNOTE.TXT">PKWare's
Zip specification</see> describes how times are stored in the zip file,
the full precision of the <c>System.DateTime</c> datatype is not stored
for the last modified time when saving zip files. For more information on
how times are formatted, see the PKZip specification.
</para>
<para>
The actual last modified time of a file can be stored in multiple ways in
the zip file, and they are not mutually exclusive:
</para>
<list type="bullet">
<item>
In the so-called "DOS" format, which has a 2-second precision. Values
are rounded to the nearest even second. For example, if the time on the
file is 12:34:43, then it will be stored as 12:34:44. This first value
is accessible via the <c>LastModified</c> property. This value is always
present in the metadata for each zip entry. In some cases the value is
invalid, or zero.
</item>
<item>
In the so-called "Windows" or "NTFS" format, as an 8-byte integer
quantity expressed as the number of 1/10 milliseconds (in other words
the number of 100 nanosecond units) since January 1, 1601 (UTC). This
format is how Windows represents file times. This time is accessible
via the <c>ModifiedTime</c> property.
</item>
<item>
In the "Unix" format, a 4-byte quantity specifying the number of seconds since
January 1, 1970 UTC.
</item>
<item>
In an older format, now deprecated but still used by some current
tools. This format is also a 4-byte quantity specifying the number of
seconds since January 1, 1970 UTC.
</item>
</list>
<para>
Zip tools and libraries will always at least handle (read or write) the
DOS time, and may also handle the other time formats. Keep in mind that
while the names refer to particular operating systems, there is nothing in
the time formats themselves that prevents their use on other operating
systems.
</para>
<para>
When reading ZIP files, The DotNetZip library reads the Windoes-formatted
time, if it is stored in the entry, and sets both <c>LastModified</c> and
<c>ModifiedTime</c> to that value. When writing ZIP files, the DotNetZip
library by default will write both time quantities. It can also emit the
Unix-formatted time if desired (See <see cref="P:Ionic.Zip.ZipEntry.EmitTimesInUnixFormatWhenSaving" />.)
</para>
<para>
The last modified time of the file created upon a call to
<c>ZipEntry.Extract()</c> may be adjusted during extraction to compensate
for differences in how the .NET Base Class Library deals with daylight
saving time (DST) versus how the Windows filesystem deals with daylight
saving time. Raymond Chen <see href="http://blogs.msdn.com/oldnewthing/archive/2003/10/24/55413.aspx">provides
some good context</see>.
</para>
<para>
In a nutshell: Daylight savings time rules change regularly. In 2007, for
example, the inception week of DST changed. In 1977, DST was in place all
year round. In 1945, likewise. And so on. Win32 does not attempt to
guess which time zone rules were in effect at the time in question. It
will render a time as "standard time" and allow the app to change to DST
as necessary. .NET makes a different choice.
</para>
<para>
Compare the output of FileInfo.LastWriteTime.ToString("f") with what you
see in the Windows Explorer property sheet for a file that was last
written to on the other side of the DST transition. For example, suppose
the file was last modified on October 17, 2003, during DST but DST is not
currently in effect. Explorer's file properties reports Thursday, October
17, 2003, 8:45:38 AM, but .NETs FileInfo reports Thursday, October 17,
2003, 9:45 AM.
</para>
<para>
Win32 says, "Thursday, October 17, 2002 8:45:38 AM PST". Note: Pacific
STANDARD Time. Even though October 17 of that year occurred during Pacific
Daylight Time, Win32 displays the time as standard time because that's
what time it is NOW.
</para>
<para>
.NET BCL assumes that the current DST rules were in place at the time in
question. So, .NET says, "Well, if the rules in effect now were also in
effect on October 17, 2003, then that would be daylight time" so it
displays "Thursday, October 17, 2003, 9:45 AM PDT" - daylight time.
</para>
<para>
So .NET gives a value which is more intuitively correct, but is also
potentially incorrect, and which is not invertible. Win32 gives a value
which is intuitively incorrect, but is strictly correct.
</para>
<para>
Because of this funkiness, this library adds one hour to the LastModified
time on the extracted file, if necessary. That is to say, if the time in
question had occurred in what the .NET Base Class Library assumed to be
DST. This assumption may be wrong given the constantly changing DST rules,
but it is the best we can do.
</para>
</remarks>
</member>
<member name="P:Ionic.Zip.ZipEntry.ModifiedTime">
<summary>
Last Modified time for the file represented by the entry.
</summary>
<remarks>
<para>
This value corresponds to the "last modified" time in the NTFS file times
as described in <see href="http://www.pkware.com/documents/casestudies/APPNOTE.TXT">the Zip
specification</see>. When getting this property, the value may be
different from <see cref="P:Ionic.Zip.ZipEntry.LastModified" />. When setting the property,
the <see cref="P:Ionic.Zip.ZipEntry.LastModified" /> property also gets set, but with a lower
precision.
</para>
<para>
Let me explain. It's going to take a while, so get
comfortable. Originally, waaaaay back in 1989 when the ZIP specification
was originally described by the esteemed Mr. Phil Katz, the dominant
operating system of the time was MS-DOS. MSDOS stored file times with a
2-second precision, because, c'mon, <em>who is ever going to need better
resolution than THAT?</em> And so ZIP files, regardless of the platform on
which the zip file was created, store file times in exactly <see href="http://www.vsft.com/hal/dostime.htm">the same format that DOS used
in 1989</see>.
</para>
<para>
Since then, the ZIP spec has evolved, but the internal format for file
timestamps remains the same. Despite the fact that the way times are
stored in a zip file is rooted in DOS heritage, any program on any
operating system can format a time in this way, and most zip tools and
libraries DO - they round file times to the nearest even second and store
it just like DOS did 25+ years ago.
</para>
<para>
PKWare extended the ZIP specification to allow a zip file to store what
are called "NTFS Times" and "Unix(tm) times" for a file. These are the
<em>last write</em>, <em>last access</em>, and <em>file creation</em>
times of a particular file. These metadata are not actually specific to
NTFS or Unix. They are tracked for each file by NTFS and by various Unix
filesystems, but they are also tracked by other filesystems, too. The key
point is that the times are <em>formatted in the zip file</em> in the same
way that NTFS formats the time (ticks since win32 epoch), or in the same
way that Unix formats the time (seconds since Unix epoch).
</para>
<para>
These extended times are higher precision quantities than the DOS time.
As described above, the (DOS) LastModified has a precision of 2 seconds.
The Unix time is stored with a precision of 1 second. The NTFS time is
stored with a precision of 0.0000001 seconds. The quantities are easily
convertible, except for the loss of precision you may incur.
</para>
<para>
A zip archive can store the {C,A,M} times in NTFS format, in Unix format,
or not at all. Often a tool running on Unix or Mac will embed the times
in Unix format (1 second precision), while WinZip running on Windows might
embed the times in NTFS format (precision of of 0.0000001 seconds). When
reading a zip file with these "extended" times, in either format,
DotNetZip represents the values with the
<c>ModifiedTime</c>, <c>AccessedTime</c> and <c>CreationTime</c>
properties on the <c>ZipEntry</c>.
</para>
<para>
As with the DOS time, any tool or library running on any operating system
is capable of formatting a time in one of these ways and embedding it into
the zip file. The key is, not all zip tools or libraries support all these
formats. Storing the higher-precision times for each entry is optional
for zip files, and many tools and libraries don't use the higher precision
quantities at all, though it is much nicer than the DOS time. And futher,
there are also cases where the timestamp of the file entry is not known,
and is not stored. For example, this happens when content for the entry is
obtained from a stream. The bottom line is that the higher-resolution
times, in either format, are not guaranteed to be present for a ZipEntry.
The old DOS time, represented by <see cref="P:Ionic.Zip.ZipEntry.LastModified" />, is guaranteed
to be present, though it sometimes unset.
</para>
<para>
Ok, getting back to the question about how the <c>LastModified</c>
property relates to this <c>ModifiedTime</c>
property... <c>LastModified</c> is always set, while <c>ModifiedTime</c>
is not. (The other times stored in the <em>NTFS times extension</em>,
<c>CreationTime</c> and <c>AccessedTime</c> also may not be set on an
entry that is read from an existing zip file.) When reading a zip file,
then <c>LastModified</c> takes the DOS time that is stored with the
file. If the DOS time has been stored as zero in the zipfile, then this
library will use <c>DateTime.Now</c> for the <c>LastModified</c> value.
If the ZIP file was created by an evolved tool, then there will also be
NTFS times in the zip file. In that case, this library will read those
times, and set <c>LastModified</c> and <c>ModifiedTime</c> to the same
value, the one corresponding to the last write time of the file. If there
are no "NTFS times" stored for the entry, then <c>ModifiedTime</c> remains
unset (likewise <c>AccessedTime</c> and <c>CreationTime</c>), and
<c>LastModified</c> keeps its DOS time.
</para>
<para>
When creating zip files with this library, by default the extended time
properties (<c>ModifiedTime</c>, <c>AccessedTime</c>, and
<c>CreationTime</c>) are set on the ZipEntry instance, and these data are
stored in the zip archive for each entry, in NTFS format. If you add an
entry from an actual filesystem file, then the entry gets the actual file
times for that file, to NTFS-level precision. If you add an entry from a
stream, or a string, then the times get the value <c>DateTime.Now</c>. In
this case <c>LastModified</c> and <c>ModifiedTime</c> will be identical,
to 2 seconds of precision. You can explicitly set the
<c>CreationTime</c>, <c>AccessedTime</c>, and <c>ModifiedTime</c> of an
entry using the property setters. If you want to set all of those
quantities, it's more efficient to use the <see cref="M:Ionic.Zip.ZipEntry.SetEntryTimes(System.DateTime,System.DateTime,System.DateTime)" /> method. Those
changes are not made permanent in the zip file until you call <see cref="M:Ionic.Zip.ZipFile.Save" /> or one of its cousins.
</para>
<para>
When creating a zip file, you can override the default behavior for
formatting times in the zip file, disabling the embedding of file times in
NTFS format or enabling the storage of file times in Unix format, or both.
You may want to do this, for example, when creating a zip file on Windows,
that will be consumed on a Mac, by an application that is not hip to the
"NTFS times" format. To do this, use the <see cref="P:Ionic.Zip.ZipEntry.EmitTimesInWindowsFormatWhenSaving" /> and <see cref="P:Ionic.Zip.ZipEntry.EmitTimesInUnixFormatWhenSaving" /> properties. A valid zip file may
store the file times in both formats. But, there are no guarantees that a
program running on Mac or Linux will gracefully handle the NTFS Formatted
times, or that a non-DotNetZip-powered application running on Windows will
be able to handle file times in Unix format. When in doubt, test.
</para>
<para>
I'll bet you didn't think one person could type so much about time, eh?
And reading it was so enjoyable, too! Well, in appreciation, <see href="http://cheeso.members.winisp.net/DotNetZipDonate.aspx">maybe you
should donate</see>?
</para>
</remarks>
<seealso cref="P:Ionic.Zip.ZipEntry.AccessedTime" />
<seealso cref="P:Ionic.Zip.ZipEntry.CreationTime" />
<seealso cref="P:Ionic.Zip.ZipEntry.LastModified" />
<seealso cref="M:Ionic.Zip.ZipEntry.SetEntryTimes(System.DateTime,System.DateTime,System.DateTime)" />
</member>
<member name="P:Ionic.Zip.ZipEntry.AccessedTime">
<summary>
Last Access time for the file represented by the entry.
</summary>
<remarks>
This value may or may not be meaningful. If the <c>ZipEntry</c> was read from an existing
Zip archive, this information may not be available. For an explanation of why, see
<see cref="P:Ionic.Zip.ZipEntry.ModifiedTime" />.
</remarks>
<seealso cref="P:Ionic.Zip.ZipEntry.ModifiedTime" />
<seealso cref="P:Ionic.Zip.ZipEntry.CreationTime" />
<seealso cref="M:Ionic.Zip.ZipEntry.SetEntryTimes(System.DateTime,System.DateTime,System.DateTime)" />
</member>
<member name="P:Ionic.Zip.ZipEntry.CreationTime">
<summary>
The file creation time for the file represented by the entry.
</summary>
<remarks>
This value may or may not be meaningful. If the <c>ZipEntry</c> was read
from an existing zip archive, and the creation time was not set on the entry
when the zip file was created, then this property may be meaningless. For an
explanation of why, see <see cref="P:Ionic.Zip.ZipEntry.ModifiedTime" />.
</remarks>
<seealso cref="P:Ionic.Zip.ZipEntry.ModifiedTime" />
<seealso cref="P:Ionic.Zip.ZipEntry.AccessedTime" />
<seealso cref="M:Ionic.Zip.ZipEntry.SetEntryTimes(System.DateTime,System.DateTime,System.DateTime)" />
</member>
<member name="P:Ionic.Zip.ZipEntry.EmitTimesInWindowsFormatWhenSaving">
<summary>
Specifies whether the Creation, Access, and Modified times for the given
entry will be emitted in "Windows 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 entry should or should not be stored
in the zip archive in the format used by Windows. The default value of
this property is <c>true</c>.
</para>
<para>
When adding an entry from a file or directory, the Creation (<see cref="P:Ionic.Zip.ZipEntry.CreationTime" />), Access (<see cref="P:Ionic.Zip.ZipEntry.AccessedTime" />), and Modified
(<see cref="P:Ionic.Zip.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="M:Ionic.Zip.ZipEntry.SetEntryTimes(System.DateTime,System.DateTime,System.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 Jan 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.
</para>
<para>
Not all zip 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. Although the time values are
easily convertible, subject to a loss of precision, 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="P:Ionic.Zip.ZipEntry.ModifiedTime" />, <see cref="P:Ionic.Zip.ZipEntry.AccessedTime" />, and <see cref="P:Ionic.Zip.ZipEntry.CreationTime" />.
</para>
<para>
This property is not mutually exclusive from the <see cref="P:Ionic.Zip.ZipEntry.EmitTimesInUnixFormatWhenSaving" /> property. It is
possible that a zip entry can embed the timestamps in both forms, one
form, or neither. But, there are no guarantees that a program running on
Mac or Linux will gracefully handle NTFS Formatted times, or that a
non-DotNetZip-powered application running on Windows will be able to
handle file times in Unix format. When in doubt, test.
</para>
<para>
Normally you will use the <see cref="P:Ionic.Zip.ZipFile.EmitTimesInWindowsFormatWhenSaving">ZipFile.EmitTimesInWindowsFormatWhenSaving</see>
property, to specify the behavior for all entries in a zip, rather than
the property on each individual entry.
</para>
</remarks>
<seealso cref="M:Ionic.Zip.ZipEntry.SetEntryTimes(System.DateTime,System.DateTime,System.DateTime)" />
<seealso cref="P:Ionic.Zip.ZipEntry.EmitTimesInUnixFormatWhenSaving" />
<seealso cref="P:Ionic.Zip.ZipEntry.CreationTime" />
<seealso cref="P:Ionic.Zip.ZipEntry.AccessedTime" />
<seealso cref="P:Ionic.Zip.ZipEntry.ModifiedTime" />
</member>
<member name="P:Ionic.Zip.ZipEntry.EmitTimesInUnixFormatWhenSaving">
<summary>
Specifies whether the Creation, Access, and Modified times for the given
entry 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 entry 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="P:Ionic.Zip.ZipEntry.CreationTime" />), Access (<see cref="P:Ionic.Zip.ZipEntry.AccessedTime" />), and Modified
(<see cref="P:Ionic.Zip.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="M:Ionic.Zip.ZipEntry.SetEntryTimes(System.DateTime,System.DateTime,System.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 Jan 1, 1601 UTC. The other is a format Unix applications typically
use: seconds since Jan 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.
</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. Although the time values are
easily convertible, subject to a loss of precision, 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="P:Ionic.Zip.ZipEntry.ModifiedTime" />, <see cref="P:Ionic.Zip.ZipEntry.AccessedTime" />, and <see cref="P:Ionic.Zip.ZipEntry.CreationTime" />.
</para>
<para>
This property is not mutually exclusive from the <see cref="P:Ionic.Zip.ZipEntry.EmitTimesInWindowsFormatWhenSaving" /> property. It is
possible that a zip entry can embed the timestamps in both forms, one
form, or neither. But, there are no guarantees that a program running on
Mac or Linux will gracefully handle NTFS Formatted times, or that a
non-DotNetZip-powered application running on Windows will be able to
handle file times in Unix format. When in doubt, test.
</para>
<para>
Normally you will use the <see cref="P:Ionic.Zip.ZipFile.EmitTimesInUnixFormatWhenSaving">ZipFile.EmitTimesInUnixFormatWhenSaving</see>
property, to specify the behavior for all entries, rather than the
property on each individual entry.
</para>
</remarks>
<seealso cref="M:Ionic.Zip.ZipEntry.SetEntryTimes(System.DateTime,System.DateTime,System.DateTime)" />
<seealso cref="P:Ionic.Zip.ZipEntry.EmitTimesInWindowsFormatWhenSaving" />
<seealso cref="P:Ionic.Zip.ZipFile.EmitTimesInUnixFormatWhenSaving" />
<seealso cref="P:Ionic.Zip.ZipEntry.CreationTime" />
<seealso cref="P:Ionic.Zip.ZipEntry.AccessedTime" />
<seealso cref="P:Ionic.Zip.ZipEntry.ModifiedTime" />
</member>
<member name="P:Ionic.Zip.ZipEntry.Timestamp">
<summary>
The type of timestamp attached to the ZipEntry.
</summary>
<remarks>
This property is valid only for a ZipEntry that was read from a zip archive.
It indicates the type of timestamp attached to the entry.
</remarks>
<seealso cref="P:Ionic.Zip.ZipEntry.EmitTimesInWindowsFormatWhenSaving" />
<seealso cref="P:Ionic.Zip.ZipEntry.EmitTimesInUnixFormatWhenSaving" />
</member>
<member name="P:Ionic.Zip.ZipEntry.Attributes">
<summary>
The file attributes for the entry.
</summary>
<remarks>
<para>
The <see cref="T:System.IO.FileAttributes">attributes</see> in NTFS include
ReadOnly, Archive, Hidden, System, and Indexed. When adding a
<c>ZipEntry</c> to a ZipFile, these attributes are set implicitly when
adding an entry from the filesystem. When adding an entry from a stream
or string, the Attributes are not set implicitly. Regardless of the way
an entry was added to a <c>ZipFile</c>, you can set the attributes
explicitly if you like.
</para>
<para>
When reading a <c>ZipEntry</c> from a <c>ZipFile</c>, the attributes are
set according to the data stored in the <c>ZipFile</c>. If you extract the
entry from the archive to a filesystem file, DotNetZip will set the
attributes on the resulting file accordingly.
</para>
<para>
The attributes can be set explicitly by the application. For example the
application may wish to set the <c>FileAttributes.ReadOnly</c> bit for all
entries added to an archive, so that on unpack, this attribute will be set
on the extracted file. Any changes you make to this property are made
permanent only when you call a <c>Save()</c> method on the <c>ZipFile</c>
instance that contains the ZipEntry.
</para>
<para>
For example, an application may wish to zip up a directory and set the
ReadOnly bit on every file in the archive, so that upon later extraction,
the resulting files will be marked as ReadOnly. Not every extraction tool
respects these attributes, but if you unpack with DotNetZip, as for
example in a self-extracting archive, then the attributes will be set as
they are stored in the <c>ZipFile</c>.
</para>
<para>
These attributes may not be interesting or useful if the resulting archive
is extracted on a non-Windows platform. How these attributes get used
upon extraction depends on the platform and tool used.
</para>
</remarks>
</member>
<member name="P:Ionic.Zip.ZipEntry.LocalFileName">
<summary>
The name of the filesystem file, referred to by the ZipEntry.
</summary>
<remarks>
<para>
This property specifies the thing-to-be-zipped on disk, and is set only
when the <c>ZipEntry</c> is being created from a filesystem file. If the
<c>ZipFile</c> is instantiated by reading an existing .zip archive, then
the LocalFileName will be <c>null</c> (<c>Nothing</c> in VB).
</para>
<para>
When it is set, the value of this property may be different than <see cref="P:Ionic.Zip.ZipEntry.FileName" />, which is the path used in the archive itself. If you
call <c>Zip.AddFile("foop.txt", AlternativeDirectory)</c>, then the path
used for the <c>ZipEntry</c> within the zip archive will be different
than this path.
</para>
<para>
If the entry is being added from a stream, then this is null (Nothing in VB).
</para>
</remarks>
<seealso cref="P:Ionic.Zip.ZipEntry.FileName" />
</member>
<member name="P:Ionic.Zip.ZipEntry.FileName">
<summary>
The name of the file contained in the ZipEntry.
</summary>
<remarks>
<para>
This is the name of the entry in the <c>ZipFile</c> itself. When creating
a zip archive, if the <c>ZipEntry</c> has been created from a filesystem
file, via a call to <see cref="M:Ionic.Zip.ZipFile.AddFile(System.String,System.String)" /> or <see cref="M:Ionic.Zip.ZipFile.AddItem(System.String,System.String)" />, or a related overload, the value
of this property is derived from the name of that file. The
<c>FileName</c> property does not include drive letters, and may include a
different directory path, depending on the value of the
<c>directoryPathInArchive</c> parameter used when adding the entry into
the <c>ZipFile</c>.
</para>
<para>
In some cases there is no related filesystem file - for example when a
<c>ZipEntry</c> is created using <see cref="M:Ionic.Zip.ZipFile.AddEntry(System.String,System.String)" /> or one of the similar overloads. In this case, the value of
this property is derived from the fileName and the directory path passed
to that method.
</para>
<para>
When reading a zip file, this property takes the value of the entry name
as stored in the zip file. If you extract such an entry, the extracted
file will take the name given by this property.
</para>
<para>
Applications can set this property when creating new zip archives or when
reading existing archives. When setting this property, the actual value
that is set will replace backslashes with forward slashes, in accordance
with <see href="http://www.pkware.com/documents/casestudies/APPNOTE.TXT">the Zip
specification</see>, for compatibility with Unix(tm) and ... get
this.... Amiga!
</para>
<para>
If an application reads a <c>ZipFile</c> via <see cref="M:Ionic.Zip.ZipFile.Read(System.String)" /> or a related overload, and then explicitly
sets the FileName on an entry contained within the <c>ZipFile</c>, and
then calls <see cref="M:Ionic.Zip.ZipFile.Save" />, the application will effectively
rename the entry within the zip archive.