node-webodf

File: APPNOTE.TXT - .ZIP File Format Specification Version: 6.3.2 Revised: September 28, 2007 Copyright (c) 1989 - 2007 PKWARE Inc., All Rights Reserved. The use of certain technological aspects disclosed in the current APPNOTE is available pursuant to the below section entitled "Incorporating PKWARE Proprietary Technology into Your Product". I. Purpose ---------- This specification is intended to define a cross-platform, interoperable file storage and transfer format. Since its first publication in 1989, PKWARE has remained committed to ensuring the interoperability of the .ZIP file format through publication and maintenance of this specification. We trust that all .ZIP compatible vendors and application developers that have adopted and benefited from this format will share and support this commitment to interoperability. II. Contacting PKWARE --------------------- PKWARE, Inc. 648 N. Plankinton Avenue, Suite 220 Milwaukee, WI 53203 +1-414-289-9788 +1-414-289-9789 FAX zipformat@pkware.com III. Disclaimer --------------- Although PKWARE will attempt to supply current and accurate information relating to its file formats, algorithms, and the subject programs, the possibility of error or omission cannot be eliminated. PKWARE therefore expressly disclaims any warranty that the information contained in the associated materials relating to the subject programs and/or the format of the files created or accessed by the subject programs and/or the algorithms used by the subject programs, or any other matter, is current, correct or accurate as delivered. Any risk of damage due to any possible inaccurate information is assumed by the user of the information. Furthermore, the information relating to the subject programs and/or the file formats created or accessed by the subject programs and/or the algorithms used by the subject programs is subject to change without notice. If the version of this file is marked as a NOTIFICATION OF CHANGE, the content defines an Early Feature Specification (EFS) change to the .ZIP file format that may be subject to modification prior to publication of the Final Feature Specification (FFS). This document may also contain information on Planned Feature Specifications (PFS) defining recognized future extensions. IV. Change Log -------------- Version Change Description Date ------- ------------------ ---------- 5.2 -Single Password Symmetric Encryption 06/02/2003 storage 6.1.0 -Smartcard compatibility 01/20/2004 -Documentation on certificate storage 6.2.0 -Introduction of Central Directory 04/26/2004 Encryption for encrypting metadata -Added OS/X to Version Made By values 6.2.1 -Added Extra Field placeholder for 04/01/2005 POSZIP using ID 0x4690 -Clarified size field on "zip64 end of central directory record" 6.2.2 -Documented Final Feature Specification 01/06/2006 for Strong Encryption -Clarifications and typographical corrections 6.3.0 -Added tape positioning storage 09/29/2006 parameters -Expanded list of supported hash algorithms -Expanded list of supported compression algorithms -Expanded list of supported encryption algorithms -Added option for Unicode filename storage -Clarifications for consistent use of Data Descriptor records -Added additional "Extra Field" definitions 6.3.1 -Corrected standard hash values for 04/11/2007 SHA-256/384/512 6.3.2 -Added compression method 97 09/28/2007 -Documented InfoZIP "Extra Field" values for UTF-8 file name and file comment storage V. General Format of a .ZIP file -------------------------------- Files stored in arbitrary order. Large .ZIP files can span multiple volumes or be split into user-defined segment sizes. All values are stored in little-endian byte order unless otherwise specified. Overall .ZIP file format: [local file header 1] [file data 1] [data descriptor 1] . . . [local file header n] [file data n] [data descriptor n] [archive decryption header] [archive extra data record] [central directory] [zip64 end of central directory record] [zip64 end of central directory locator] [end of central directory record] A. Local file header: local file header signature 4 bytes (0x04034b50) version needed to extract 2 bytes general purpose bit flag 2 bytes compression method 2 bytes last mod file time 2 bytes last mod file date 2 bytes crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes file name length 2 bytes extra field length 2 bytes file name (variable size) extra field (variable size) B. File data Immediately following the local header for a file is the compressed or stored data for the file. The series of [local file header][file data][data descriptor] repeats for each file in the .ZIP archive. C. Data descriptor: crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes This descriptor exists only if bit 3 of the general purpose bit flag is set (see below). It is byte aligned and immediately follows the last byte of compressed data. This descriptor is used only when it was not possible to seek in the output .ZIP file, e.g., when the output .ZIP file was standard output or a non-seekable device. For ZIP64(tm) format archives, the compressed and uncompressed sizes are 8 bytes each. When compressing files, compressed and uncompressed sizes should be stored in ZIP64 format (as 8 byte values) when a files size exceeds 0xFFFFFFFF. However ZIP64 format may be used regardless of the size of a file. When extracting, if the zip64 extended information extra field is present for the file the compressed and uncompressed sizes will be 8 byte values. Although not originally assigned a signature, the value 0x08074b50 has commonly been adopted as a signature value for the data descriptor record. Implementers should be aware that ZIP files may be encountered with or without this signature marking data descriptors and should account for either case when reading ZIP files to ensure compatibility. When writing ZIP files, it is recommended to include the signature value marking the data descriptor record. When the signature is used, the fields currently defined for the data descriptor record will immediately follow the signature. An extensible data descriptor will be released in a future version of this APPNOTE. This new record is intended to resolve conflicts with the use of this record going forward, and to provide better support for streamed file processing. When the Central Directory Encryption method is used, the data descriptor record is not required, but may be used. If present, and bit 3 of the general purpose bit field is set to indicate its presence, the values in fields of the data descriptor record should be set to binary zeros. D. Archive decryption header: The Archive Decryption Header is introduced in version 6.2 of the ZIP format specification. This record exists in support of the Central Directory Encryption Feature implemented as part of the Strong Encryption Specification as described in this document. When the Central Directory Structure is encrypted, this decryption header will precede the encrypted data segment. The encrypted data segment will consist of the Archive extra data record (if present) and the encrypted Central Directory Structure data. The format of this data record is identical to the Decryption header record preceding compressed file data. If the central directory structure is encrypted, the location of the start of this data record is determined using the Start of Central Directory field in the Zip64 End of Central Directory record. Refer to the section on the Strong Encryption Specification for information on the fields used in the Archive Decryption Header record. E. Archive extra data record: archive extra data signature 4 bytes (0x08064b50) extra field length 4 bytes extra field data (variable size) The Archive Extra Data Record is introduced in version 6.2 of the ZIP format specification. This record exists in support of the Central Directory Encryption Feature implemented as part of the Strong Encryption Specification as described in this document. When present, this record immediately precedes the central directory data structure. The size of this data record will be included in the Size of the Central Directory field in the End of Central Directory record. If the central directory structure is compressed, but not encrypted, the location of the start of this data record is determined using the Start of Central Directory field in the Zip64 End of Central Directory record. F. Central directory structure: [file header 1] . . . [file header n] [digital signature] File header: central file header signature 4 bytes (0x02014b50) version made by 2 bytes version needed to extract 2 bytes general purpose bit flag 2 bytes compression method 2 bytes last mod file time 2 bytes last mod file date 2 bytes crc-32 4 bytes compressed size 4 bytes uncompressed size 4 bytes file name length 2 bytes extra field length 2 bytes file comment length 2 bytes disk number start 2 bytes internal file attributes 2 bytes external file attributes 4 bytes relative offset of local header 4 bytes file name (variable size) extra field (variable size) file comment (variable size) Digital signature: header signature 4 bytes (0x05054b50) size of data 2 bytes signature data (variable size) With the introduction of the Central Directory Encryption feature in version 6.2 of this specification, the Central Directory Structure may be stored both compressed and encrypted. Although not required, it is assumed when encrypting the Central Directory Structure, that it will be compressed for greater storage efficiency. Information on the Central Directory Encryption feature can be found in the section describing the Strong Encryption Specification. The Digital Signature record will be neither compressed nor encrypted. G. Zip64 end of central directory record zip64 end of central dir signature 4 bytes (0x06064b50) size of zip64 end of central directory record 8 bytes version made by 2 bytes version needed to extract 2 bytes number of this disk 4 bytes number of the disk with the start of the central directory 4 bytes total number of entries in the central directory on this disk 8 bytes total number of entries in the central directory 8 bytes size of the central directory 8 bytes offset of start of central directory with respect to the starting disk number 8 bytes zip64 extensible data sector (variable size) The value stored into the "size of zip64 end of central directory record" should be the size of the remaining record and should not include the leading 12 bytes. Size = SizeOfFixedFields + SizeOfVariableData - 12. The above record structure defines Version 1 of the zip64 end of central directory record. Version 1 was implemented in versions of this specification preceding 6.2 in support of the ZIP64 large file feature. The introduction of the Central Directory Encryption feature implemented in version 6.2 as part of the Strong Encryption Specification defines Version 2 of this record structure. Refer to the section describing the Strong Encryption Specification for details on the version 2 format for this record. Special purpose data may reside in the zip64 extensible data sector field following either a V1 or V2 version of this record. To ensure identification of this special purpose data it must include an identifying header block consisting of the following: Header ID - 2 bytes Data Size - 4 bytes The Header ID field indicates the type of data that is in the data block that follows. Data Size identifies the number of bytes that follow for this data block type. Multiple special purpose data blocks may be present, but each must be preceded by a Header ID and Data Size field. Current mappings of Header ID values supported in this field are as defined in APPENDIX C. H. Zip64 end of central directory locator zip64 end of central dir locator signature 4 bytes (0x07064b50) number of the disk with the start of the zip64 end of central directory 4 bytes relative offset of the zip64 end of central directory record 8 bytes total number of disks 4 bytes I. End of central directory record: end of central dir signature 4 bytes (0x06054b50) number of this disk 2 bytes number of the disk with the start of the central directory 2 bytes total number of entries in the central directory on this disk 2 bytes total number of entries in the central directory 2 bytes size of the central directory 4 bytes offset of start of central directory with respect to the starting disk number 4 bytes .ZIP file comment length 2 bytes .ZIP file comment (variable size) J. Explanation of fields: version made by (2 bytes) The upper byte indicates the compatibility of the file attribute information. If the external file attributes are compatible with MS-DOS and can be read by PKZIP for DOS version 2.04g then this value will be zero. If these attributes are not compatible, then this value will identify the host system on which the attributes are compatible. Software can use this information to determine the line record format for text files etc. The current mappings are: 0 - MS-DOS and OS/2 (FAT / VFAT / FAT32 file systems) 1 - Amiga 2 - OpenVMS 3 - UNIX 4 - VM/CMS 5 - Atari ST 6 - OS/2 H.P.F.S. 7 - Macintosh 8 - Z-System 9 - CP/M 10 - Windows NTFS 11 - MVS (OS/390 - Z/OS) 12 - VSE 13 - Acorn Risc 14 - VFAT 15 - alternate MVS 16 - BeOS 17 - Tandem 18 - OS/400 19 - OS/X (Darwin) 20 thru 255 - unused The lower byte indicates the ZIP specification version (the version of this document) supported by the software used to encode the file. The value/10 indicates the major version number, and the value mod 10 is the minor version number. version needed to extract (2 bytes) The minimum supported ZIP specification version needed to extract the file, mapped as above. This value is based on the specific format features a ZIP program must support to be able to extract the file. If multiple features are applied to a file, the minimum version should be set to the feature having the highest value. New features or feature changes affecting the published format specification will be implemented using higher version numbers than the last published value to avoid conflict. Current minimum feature versions are as defined below: 1.0 - Default value 1.1 - File is a volume label 2.0 - File is a folder (directory) 2.0 - File is compressed using Deflate compression 2.0 - File is encrypted using traditional PKWARE encryption 2.1 - File is compressed using Deflate64(tm) 2.5 - File is compressed using PKWARE DCL Implode 2.7 - File is a patch data set 4.5 - File uses ZIP64 format extensions 4.6 - File is compressed using BZIP2 compression* 5.0 - File is encrypted using DES 5.0 - File is encrypted using 3DES 5.0 - File is encrypted using original RC2 encryption 5.0 - File is encrypted using RC4 encryption 5.1 - File is encrypted using AES encryption 5.1 - File is encrypted using corrected RC2 encryption** 5.2 - File is encrypted using corrected RC2-64 encryption** 6.1 - File is encrypted using non-OAEP key wrapping*** 6.2 - Central directory encryption 6.3 - File is compressed using LZMA 6.3 - File is compressed using PPMd+ 6.3 - File is encrypted using Blowfish 6.3 - File is encrypted using Twofish * Early 7.x (pre-7.2) versions of PKZIP incorrectly set the version needed to extract for BZIP2 compression to be 50 when it should have been 46. ** Refer to the section on Strong Encryption Specification for additional information regarding RC2 corrections. *** Certificate encryption using non-OAEP key wrapping is the intended mode of operation for all versions beginning with 6.1. Support for OAEP key wrapping should only be used for backward compatibility when sending ZIP files to be opened by versions of PKZIP older than 6.1 (5.0 or 6.0). + Files compressed using PPMd should set the version needed to extract field to 6.3, however, not all ZIP programs enforce this and may be unable to decompress data files compressed using PPMd if this value is set. When using ZIP64 extensions, the corresponding value in the zip64 end of central directory record should also be set. This field should be set appropriately to indicate whether Version 1 or Version 2 format is in use. general purpose bit flag: (2 bytes) Bit 0: If set, indicates that the file is encrypted. (For Method 6 - Imploding) Bit 1: If the compression method used was type 6, Imploding, then this bit, if set, indicates an 8K sliding dictionary was used. If clear, then a 4K sliding dictionary was used. Bit 2: If the compression method used was type 6, Imploding, then this bit, if set, indicates 3 Shannon-Fano trees were used to encode the sliding dictionary output. If clear, then 2 Shannon-Fano trees were used. (For Methods 8 and 9 - Deflating) Bit 2 Bit 1 0 0 Normal (-en) compression option was used. 0 1 Maximum (-exx/-ex) compression option was used. 1 0 Fast (-ef) compression option was used. 1 1 Super Fast (-es) compression option was used. (For Method 14 - LZMA) Bit 1: If the compression method used was type 14, LZMA, then this bit, if set, indicates an end-of-stream (EOS) marker is used to mark the end of the compressed data stream. If clear, then an EOS marker is not present and the compressed data size must be known to extract. Note: Bits 1 and 2 are undefined if the compression method is any other. Bit 3: If this bit is set, the fields crc-32, compressed size and uncompressed size are set to zero in the local header. The correct values are put in the data descriptor immediately following the compressed data. (Note: PKZIP version 2.04g for DOS only recognizes this bit for method 8 compression, newer versions of PKZIP recognize this bit for any compression method.) Bit 4: Reserved for use with method 8, for enhanced deflating. Bit 5: If this bit is set, this indicates that the file is compressed patched data. (Note: Requires PKZIP version 2.70 or greater) Bit 6: Strong encryption. If this bit is set, you should set the version needed to extract value to at least 50 and you must also set bit 0. If AES encryption is used, the version needed to extract value must be at least 51. Bit 7: Currently unused. Bit 8: Currently unused. Bit 9: Currently unused. Bit 10: Currently unused. Bit 11: Language encoding flag (EFS). If this bit is set, the filename and comment fields for this file must be encoded using UTF-8. (see APPENDIX D) Bit 12: Reserved by PKWARE for enhanced compression. Bit 13: Used when encrypting the Central Directory to indicate selected data values in the Local Header are masked to hide their actual values. See the section describing the Strong Encryption Specification for details. Bit 14: Reserved by PKWARE. Bit 15: Reserved by PKWARE. compression method: (2 bytes) (see accompanying documentation for algorithm descriptions) 0 - The file is stored (no compression) 1 - The file is Shrunk 2 - The file is Reduced with compression factor 1 3 - The file is Reduced with compression factor 2 4 - The file is Reduced with compression factor 3 5 - The file is Reduced with compression factor 4 6 - The file is Imploded 7 - Reserved for Tokenizing compression algorithm 8 - The file is Deflated 9 - Enhanced Deflating using Deflate64(tm) 10 - PKWARE Data Compression Library Imploding (old IBM TERSE) 11 - Reserved by PKWARE 12 - File is compressed using BZIP2 algorithm 13 - Reserved by PKWARE 14 - LZMA (EFS) 15 - Reserved by PKWARE 16 - Reserved by PKWARE 17 - Reserved by PKWARE 18 - File is compressed using IBM TERSE (new) 19 - IBM LZ77 z Architecture (PFS) 97 - WavPack compressed data 98 - PPMd version I, Rev 1 date and time fields: (2 bytes each) The date and time are encoded in standard MS-DOS format. If input came from standard input, the date and time are those at which compression was started for this data. If encrypting the central directory and general purpose bit flag 13 is set indicating masking, the value stored in the Local Header will be zero. CRC-32: (4 bytes) The CRC-32 algorithm was generously contributed by David Schwaderer and can be found in his excellent book "C Programmers Guide to NetBIOS" published by Howard W. Sams & Co. Inc. The 'magic number' for the CRC is 0xdebb20e3. The proper CRC pre and post conditioning is used, meaning that the CRC register is pre-conditioned with all ones (a starting value of 0xffffffff) and the value is post-conditioned by taking the one's complement of the CRC residual. If bit 3 of the general purpose flag is set, this field is set to zero in the local header and the correct value is put in the data descriptor and in the central directory. When encrypting the central directory, if the local header is not in ZIP64 format and general purpose bit flag 13 is set indicating masking, the value stored in the Local Header will be zero. compressed size: (4 bytes) uncompressed size: (4 bytes) The size of the file compressed and uncompressed, respectively. When a decryption header is present it will be placed in front of the file data and the value of the compressed file size will include the bytes of the decryption header. If bit 3 of the general purpose bit flag is set, these fields are set to zero in the local header and the correct values are put in the data descriptor and in the central directory. If an archive is in ZIP64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte ZIP64 extended information extra field. When encrypting the central directory, if the local header is not in ZIP64 format and general purpose bit flag 13 is set indicating masking, the value stored for the uncompressed size in the Local Header will be zero. file name length: (2 bytes) extra field length: (2 bytes) file comment length: (2 bytes) The length of the file name, extra field, and comment fields respectively. The combined length of any directory record and these three fields should not generally exceed 65,535 bytes. If input came from standard input, the file name length is set to zero. disk number start: (2 bytes) The number of the disk on which this file begins. If an archive is in ZIP64 format and the value in this field is 0xFFFF, the size will be in the corresponding 4 byte zip64 extended information extra field. internal file attributes: (2 bytes) Bits 1 and 2 are reserved for use by PKWARE. The lowest bit of this field indicates, if set, that the file is apparently an ASCII or text file. If not set, that the file apparently contains binary data. The remaining bits are unused in version 1.0. The 0x0002 bit of this field indicates, if set, that a 4 byte variable record length control field precedes each logical record indicating the length of the record. The record length control field is stored in little-endian byte order. This flag is independent of text control characters, and if used in conjunction with text data, includes any control characters in the total length of the record. This value is provided for mainframe data transfer support. external file attributes: (4 bytes) The mapping of the external attributes is host-system dependent (see 'version made by'). For MS-DOS, the low order byte is the MS-DOS directory attribute byte. If input came from standard input, this field is set to zero. relative offset of local header: (4 bytes) This is the offset from the start of the first disk on which this file appears, to where the local header should be found. If an archive is in ZIP64 format and the value in this field is 0xFFFFFFFF, the size will be in the corresponding 8 byte zip64 extended information extra field. file name: (Variable) The name of the file, with optional relative path. The path stored should not contain a drive or device letter, or a leading slash. All slashes should be forward slashes '/' as opposed to backwards slashes '\' for compatibility with Amiga and UNIX file systems etc. If input came from standard input, there is no file name field. If encrypting the central directory and general purpose bit flag 13 is set indicating masking, the file name stored in the Local Header will not be the actual file name. A masking value consisting of a unique hexadecimal value will be stored. This value will be sequentially incremented for each file in the archive. See the section on the Strong Encryption Specification for details on retrieving the encrypted file name. extra field: (Variable) This is for expansion. If additional information needs to be stored for special needs or for specific platforms, it should be stored here. Earlier versions of the software can then safely skip this file, and find the next file or header. This field will be 0 length in version 1.0. In order to allow different programs and different types of information to be stored in the 'extra' field in .ZIP files, the following structure should be used for all programs storing data in this field: header1+data1 + header2+data2 . . . Each header should consist of: Header ID - 2 bytes Data Size - 2 bytes Note: all fields stored in Intel low-byte/high-byte order. The Header ID field indicates the type of data that is in the following data block. Header ID's of 0 thru 31 are reserved for use by PKWARE. The remaining ID's can be used by third party vendors for proprietary usage. The current Header ID mappings defined by PKWARE are: 0x0001 Zip64 extended information extra field 0x0007 AV Info 0x0008 Reserved for extended language encoding data (PFS) (see APPENDIX D) 0x0009 OS/2 0x000a NTFS 0x000c OpenVMS 0x000d UNIX 0x000e Reserved for file stream and fork descriptors 0x000f Patch Descriptor 0x0014 PKCS#7 Store for X.509 Certificates 0x0015 X.509 Certificate ID and Signature for individual file 0x0016 X.509 Certificate ID for Central Directory 0x0017 Strong Encryption Header 0x0018 Record Management Controls 0x0019 PKCS#7 Encryption Recipient Certificate List 0x0065 IBM S/390 (Z390), AS/400 (I400) attributes - uncompressed 0x0066 Reserved for IBM S/390 (Z390), AS/400 (I400) attributes - compressed 0x4690 POSZIP 4690 (reserved) Third party mappings commonly used are: 0x07c8 Macintosh 0x2605 ZipIt Macintosh 0x2705 ZipIt Macintosh 1.3.5+ 0x2805 ZipIt Macintosh 1.3.5+ 0x334d Info-ZIP Macintosh 0x4341 Acorn/SparkFS 0x4453 Windows NT security descriptor (binary ACL) 0x4704 VM/CMS 0x470f MVS 0x4b46 FWKCS MD5 (see below) 0x4c41 OS/2 access control list (text ACL) 0x4d49 Info-ZIP OpenVMS 0x4f4c Xceed original location extra field 0x5356 AOS/VS (ACL) 0x5455 extended timestamp 0x554e Xceed unicode extra field 0x5855 Info-ZIP UNIX (original, also OS/2, NT, etc) 0x6375 Info-ZIP Unicode Comment Extra Field 0x6542 BeOS/BeBox 0x7075 Info-ZIP Unicode Path Extra Field 0x756e ASi UNIX 0x7855 Info-ZIP UNIX (new) 0xa220 Microsoft Open Packaging Growth Hint 0xfd4a SMS/QDOS Detailed descriptions of Extra Fields defined by third party mappings will be documented as information on these data structures is made available to PKWARE. PKWARE does not guarantee the accuracy of any published third party data. The Data Size field indicates the size of the following data block. Programs can use this value to skip to the next header block, passing over any data blocks that are not of interest. Note: As stated above, the size of the entire .ZIP file header, including the file name, comment, and extra field should not exceed 64K in size. In case two different programs should appropriate the same Header ID value, it is strongly recommended that each program place a unique signature of at least two bytes in size (and preferably 4 bytes or bigger) at the start of each data area. Every program should verify that its unique signature is present, in addition to the Header ID value being correct, before assuming that it is a block of known type. -Zip64 Extended Information Extra Field (0x0001): The following is the layout of the zip64 extended information "extra" block. If one of the size or offset fields in the Local or Central directory record is too small to hold the required data, a Zip64 extended information record is created. The order of the fields in the zip64 extended information record is fixed, but the fields will only appear if the corresponding Local or Central directory record field is set to 0xFFFF or 0xFFFFFFFF. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (ZIP64) 0x0001 2 bytes Tag for this "extra" block type Size 2 bytes Size of this "extra" block Original Size 8 bytes Original uncompressed file size Compressed Size 8 bytes Size of compressed data Relative Header Offset 8 bytes Offset of local header record Disk Start Number 4 bytes Number of the disk on which this file starts This entry in the Local header must include BOTH original and compressed file size fields. If encrypting the central directory and bit 13 of the general purpose bit flag is set indicating masking, the value stored in the Local Header for the original file size will be zero. -OS/2 Extra Field (0x0009): The following is the layout of the OS/2 attributes "extra" block. (Last Revision 09/05/95) Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (OS/2) 0x0009 2 bytes Tag for this "extra" block type TSize 2 bytes Size for the following data block BSize 4 bytes Uncompressed Block Size CType 2 bytes Compression type EACRC 4 bytes CRC value for uncompress block (var) variable Compressed block The OS/2 extended attribute structure (FEA2LIST) is compressed and then stored in it's entirety within this structure. There will only ever be one "block" of data in VarFields[]. -NTFS Extra Field (0x000a): The following is the layout of the NTFS attributes "extra" block. (Note: At this time the Mtime, Atime and Ctime values may be used on any WIN32 system.) Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (NTFS) 0x000a 2 bytes Tag for this "extra" block type TSize 2 bytes Size of the total "extra" block Reserved 4 bytes Reserved for future use Tag1 2 bytes NTFS attribute tag value #1 Size1 2 bytes Size of attribute #1, in bytes (var.) Size1 Attribute #1 data . . . TagN 2 bytes NTFS attribute tag value #N SizeN 2 bytes Size of attribute #N, in bytes (var.) SizeN Attribute #N data For NTFS, values for Tag1 through TagN are as follows: (currently only one set of attributes is defined for NTFS) Tag Size Description ----- ---- ----------- 0x0001 2 bytes Tag for attribute #1 Size1 2 bytes Size of attribute #1, in bytes Mtime 8 bytes File last modification time Atime 8 bytes File last access time Ctime 8 bytes File creation time -OpenVMS Extra Field (0x000c): The following is the layout of the OpenVMS attributes "extra" block. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (VMS) 0x000c 2 bytes Tag for this "extra" block type TSize 2 bytes Size of the total "extra" block CRC 4 bytes 32-bit CRC for remainder of the block Tag1 2 bytes OpenVMS attribute tag value #1 Size1 2 bytes Size of attribute #1, in bytes (var.) Size1 Attribute #1 data . . . TagN 2 bytes OpenVMS attribute tag value #N SizeN 2 bytes Size of attribute #N, in bytes (var.) SizeN Attribute #N data Rules: 1. There will be one or more of attributes present, which will each be preceded by the above TagX & SizeX values. These values are identical to the ATR$C_XXXX and ATR$S_XXXX constants which are defined in ATR.H under OpenVMS C. Neither of these values will ever be zero. 2. No word alignment or padding is performed. 3. A well-behaved PKZIP/OpenVMS program should never produce more than one sub-block with the same TagX value. Also, there will never be more than one "extra" block of type 0x000c in a particular directory record. -UNIX Extra Field (0x000d): The following is the layout of the UNIX "extra" block. Note: all fields are stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (UNIX) 0x000d 2 bytes Tag for this "extra" block type TSize 2 bytes Size for the following data block Atime 4 bytes File last access time Mtime 4 bytes File last modification time Uid 2 bytes File user ID Gid 2 bytes File group ID (var) variable Variable length data field The variable length data field will contain file type specific data. Currently the only values allowed are the original "linked to" file names for hard or symbolic links, and the major and minor device node numbers for character and block device nodes. Since device nodes cannot be either symbolic or hard links, only one set of variable length data is stored. Link files will have the name of the original file stored. This name is NOT NULL terminated. Its size can be determined by checking TSize - 12. Device entries will have eight bytes stored as two 4 byte entries (in little endian format). The first entry will be the major device number, and the second the minor device number. -PATCH Descriptor Extra Field (0x000f): The following is the layout of the Patch Descriptor "extra" block. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (Patch) 0x000f 2 bytes Tag for this "extra" block type TSize 2 bytes Size of the total "extra" block Version 2 bytes Version of the descriptor Flags 4 bytes Actions and reactions (see below) OldSize 4 bytes Size of the file about to be patched OldCRC 4 bytes 32-bit CRC of the file to be patched NewSize 4 bytes Size of the resulting file NewCRC 4 bytes 32-bit CRC of the resulting file Actions and reactions Bits Description ---- ---------------- 0 Use for auto detection 1 Treat as a self-patch 2-3 RESERVED 4-5 Action (see below) 6-7 RESERVED 8-9 Reaction (see below) to absent file 10-11 Reaction (see below) to newer file 12-13 Reaction (see below) to unknown file 14-15 RESERVED 16-31 RESERVED Actions Action Value ------ ----- none 0 add 1 delete 2 patch 3 Reactions Reaction Value -------- ----- ask 0 skip 1 ignore 2 fail 3 Patch support is provided by PKPatchMaker(tm) technology and is covered under U.S. Patents and Patents Pending. The use or implementation in a product of certain technological aspects set forth in the current APPNOTE, including those with regard to strong encryption, patching, or extended tape operations requires a license from PKWARE. Please contact PKWARE with regard to acquiring a license. -PKCS#7 Store for X.509 Certificates (0x0014): This field contains information about each of the certificates files may be signed with. When the Central Directory Encryption feature is enabled for a ZIP file, this record will appear in the Archive Extra Data Record, otherwise it will appear in the first central directory record and will be ignored in any other record. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (Store) 0x0014 2 bytes Tag for this "extra" block type TSize 2 bytes Size of the store data TData TSize Data about the store -X.509 Certificate ID and Signature for individual file (0x0015): This field contains the information about which certificate in the PKCS#7 store was used to sign a particular file. It also contains the signature data. This field can appear multiple times, but can only appear once per certificate. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (CID) 0x0015 2 bytes Tag for this "extra" block type TSize 2 bytes Size of data that follows TData TSize Signature Data -X.509 Certificate ID and Signature for central directory (0x0016): This field contains the information about which certificate in the PKCS#7 store was used to sign the central directory structure. When the Central Directory Encryption feature is enabled for a ZIP file, this record will appear in the Archive Extra Data Record, otherwise it will appear in the first central directory record. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (CDID) 0x0016 2 bytes Tag for this "extra" block type TSize 2 bytes Size of data that follows TData TSize Data -Strong Encryption Header (0x0017): Value Size Description ----- ---- ----------- 0x0017 2 bytes Tag for this "extra" block type TSize 2 bytes Size of data that follows Format 2 bytes Format definition for this record AlgID 2 bytes Encryption algorithm identifier Bitlen 2 bytes Bit length of encryption key Flags 2 bytes Processing flags CertData TSize-8 Certificate decryption extra field data (refer to the explanation for CertData in the section describing the Certificate Processing Method under the Strong Encryption Specification) -Record Management Controls (0x0018): Value Size Description ----- ---- ----------- (Rec-CTL) 0x0018 2 bytes Tag for this "extra" block type CSize 2 bytes Size of total extra block data Tag1 2 bytes Record control attribute 1 Size1 2 bytes Size of attribute 1, in bytes Data1 Size1 Attribute 1 data . . . TagN 2 bytes Record control attribute N SizeN 2 bytes Size of attribute N, in bytes DataN SizeN Attribute N data -PKCS#7 Encryption Recipient Certificate List (0x0019): This field contains information about each of the certificates used in encryption processing and it can be used to identify who is allowed to decrypt encrypted files. This field should only appear in the archive extra data record. This field is not required and serves only to aide archive modifications by preserving public encryption key data. Individual security requirements may dictate that this data be omitted to deter information exposure. Note: all fields stored in Intel low-byte/high-byte order. Value Size Description ----- ---- ----------- (CStore) 0x0019 2 bytes Tag for this "extra" block type TSize 2 bytes Size of the store data TData TSize Data about the store TData: Value Size Description ----- ---- ----------- Version 2 bytes Format version number - must 0x0001 at this time CStore (var) PKCS#7 d