ZipTV version history
---------------------------------------------------------------------------
Revision History
---------------------------------------------------------------------------
2009.1.1 Revision(s)
1. Beta version. Original release of ZipTV for Delphi 2009 with native
unicode support.
Thousands of archives have been tested and revisions included when
appropriate. ZipTV for Delphi 2009 is not backward compatible with any
prior versions of Delphi; however, we plan on continuing upgrades and
support for those versions as well. Even though prior versions of ZipTV
included support for unicode (via a conversion layer provided by the use of
a 3rd party unicode package), we strongly recommend ZipTV for Delphi 2009
for unicode support.
2008.12.13 Revision(s)
1. Included support for the proper reading and extraction of unicode
filenames stored in zip files that use extended headers as a method
of providing support for unicode filenames. Utility applications that
use this method, first write the ansi-string form of the filename to
the header, UTF8 encode it, and then write the UTF8 encoded string
value to an extended header. This method results in the writing of
one filename to a zip file four times.
There are many problems with this method. The first is the writing of
a filename four times as previously mentioned. With that in mind, if
it is determined that UTF8 encoding is required, reconstruction of the
stored ansi-string value is generally not possible anyway, so what is
the purpose of writing it to the archive? Another is that most utility
applications compressing files using this method, bypass the ansi-string
stored value and instead, read the UTF8 encoded string from the extended
header, providing no access to the stored ansi-string value - again,
what's the purpose of writing the filename four times? The zip format is
the only archive format that supports extended headers; therefore,
uniformity of unicode filename support across all supported archive formats
cannot be achieved.
The zip format contains three header types. The local header, central
header, and ending header. Filenames have always been written to a zip
archive, two times. Once in the local header and once in the central header.
With the use of an extended header to support unicode, one filename is
written to the archive four times, twice in the local header and twice in
the central header. Consider an archive containing a thousand compressed
files, a single filename has the capacity to hold up to 256 single byte
characters, and each filename stored four times.
There are three points here. Consideration for unicode in archives exists
only in the archive's compressed filenames. Compression algorithms remain
heavily byte oriented, so the compressed data will always be reconstructed
back to it's exact original decompressed state. Storing the ansi-string
version of the filename is wasted space because when an extended header flag
signals a UTF8 encoded filename, the stored ansi-string version of the
filename is bypassed, and the UTF8 encoded string value is used. Therefore,
if our default UTF8 encoding method fails, so will the method of using
extended headers. Second, the use of UTF8 encoding of filenames as the
default in ZipTV, is universal in all archive formats supported. Only zip
headers support extended headers; therefore, the method of supporting
unicode with the use of extended headers is possible only in zip files.
Third, the practice of bloating headers with junk data is reversing the
small gains that's been achieved over the years in compression ratios.
Not to imply it is not possible, but we have yet to test an archive
containing UTF8 encoded filenames that fails decoding and proper
reconstruction, even in double byte character set languages such as Arabic.
Unless we are provided with an instance where UTF8 encoded filenames in an
archive fails decoding, we favor UTF8 encoding as the default method for
writing filenames to all archive formats. ZipTV can properly read and
extract unicode filenames from a zip file compressed using extended
headers; however, we currently have no plans to pattern this method in
compressing new files to a zip file. Other utility applications wishing
to support default UTF8 encoded filenames, can simply test the stored
filename to see if it is UTF8 encoded.
Barriers in international communications are rapidly narrowing, and issues
regarding character translations between languages are lessening. Even
though great progress has been made over the past few years, it is not a
perfected science yet, especially with regard to signal to double byte
characters and reverse. We do not in any way, purport ourselves to be
experts on the subject of unicode, nor do we mean to imply that others are
wrong in their use of extended headers for unicode support. Only that we
will not unquestionably pattern our development to follow the lead of others
who have not proven a comparable level of understanding and uniformity in
their development regarding unicode issues, as the Delphi folks have in
their recent release of Delphi 2009.
We have listed our finding and reasoning for not agreeing with the use of
extended headers to support unicode filenames in zip files. As always,
opposing views are always welcome.
2. TUnGZip: this issue involved a gzip compressed tarball (.tar.gz), when
both the .gz file as well as the compressed .tar file contained stored
paths.
Archive name: distributor tar.gz
Properties:
UseStoredDirs property := true;
ExtractDir := 'c:\test';
a. Distributor.tar.gz contains one compressed file:
data01\eserverdata\contentitems\19\61\test.tar
b. data01\eserverdata\contentitems\19\61\test.tar has two files:
NRC\ NRC Handelsblad - Maandag 8 december.pdf
System\Inbox\test.001.desktop
When the UseStoredDirs property was true, the two files in test.tar were
extracted as:
1. c:\test\data01\eserverdata\contentitems\19\61\ NRC\ NRC Handelsblad - Maandag 8 december.pdf
2. c:\test\data01\eserverdata\contentitems\19\61\System\Inbox\test.001.desktop
Note the above extracted directory's combination of the values of the
ExtractDir property (c:\test), the pathname stored in the gzip archive
(data01\eserverdata\contentitems\19\61\), and the pathname stored in the tar
files (NRC\ and System\Inbox\).
Considering the property settings shown above, the correct files should be
extracted as:
1. c:\test\NRC\ NRC Handelsblad - Maandag 8 december.pdf
2. c:\test\System\Inbox\test.001.desktop
2008.9.29 Revision(s)
1. All compression components: adding files to an archive on a thumb-drive
were being handled using the objects for removable floppy drives. Fixed.
2008.8.4 Revision(s)
1. Maintenance update
2. TUnRar: A multi-volume stores an additional header at beginning offset 0
in every subsequent volume that spans a specific compressed file.
Previous versions returned the values from the first header. Values are
now obtained from a compressed file's last volume's header. Encrypted
headers are now supported.
3. FileInArchive: bug fix.
2008.4.21 Revision(s)
1. Added support for the FILE_ATTRIBUTE_REPARSE_POINT (1024) attribute:
http://msdn2.microsoft.com/en-us/library/aa365740(VS.85).aspx. This
attribute is now excluded from directory scanning when the RecurseDirs
property equals true (see the following conversation thread):
There are many reparse points (not dirs, just pointers/links to other
dirs) in Vista. The problem is, that Scan and ScanDir procedures repute
these links as normal dirs. This is not correct. For better understanding,
compress "C:\Users\MyDir" (with RecurseDirs := True) in Vista without
skipping reparse points, then open the archive and look at the content.
2008.4.20 Revision(s)
1. Unable to add/delete files from an archive with filenames containing
umlaut characters. Fixed.
2. WideString version of ZipTV & OEM encoded filenames: ZipTV was able
to manage (create/add/delete) OEM encoded files to/from an archive
created by other utilities, but some other utilities were unable read
the revised archive since the filenames were stored in widestring format.
Revised for compatibility.
2008.2.16 Revision(s)
1. TArchiveStream bug was recently introduced in this object. Fixed.
2008.1.21 Revision(s)
1. New component: TZipEncrypt. Flexability and highly configurability,
archive password management system for use with existing archives.
This originaly release supports Zip archives.
First and only component of it's kind. TZipEncrypt allows adding new,
changing existing, or assigning multiple passwords to individule or
defined range of compressed files.
No longer are you confined to only one password for all compressed
files in a Zip archive. Assign one password to a certain file, file
type, directory, or range of files and protect other files, allowing
access to only certain individules or groups.
* available as beta in registered versions. We strongly encourage
feedback and recomendations for enhancements of this component.
2007.9.24 Revision(s)
1. TUnBh: Buffer overflow when filename length is greater than 32k. Fixed.
2007.6.26 Revision(s)
1. Unable to delete a .zip's main archive comment. Fixed.
2007.5.29 Revision(s)
1. TZipRun & TZipSearch: added BZip support for utility/tool components.
2007.5.7 Revision(s)
1. TZip/TUnzip: this format can now contain more than 65536 files.
2007.3.12 Revision(s)
1. TUnGzip: bug fix: when a compressed filename matched the archive name
(with the exception of the .gz extension), the file opened for
decompressed data retained the .gz extension. Since most .gz utilities
do not store the output filename within the archive, this affected only
a select number of archives.
2007.3.8 Revision(s)
1. Compress components: added OnCreateDirectory event. In prior versions,
if the directory defined in the ArchiveFile property did not exist,
the archive was created in the current active directory. By default,
the directory defined in this property is now created if it doesn't
exist. To prevent the creation of the directory, set an OnCreateDirectory
event.
2007.2.26 Revision(s)
1. TZipTV & TUnLha: when using WideStrings (compiling with TNT_UNICODE
conditional define), .lha/lzh archives containing directories were
decoded properly. This bug appears only when compiling using
WideStrings. Corrected.
2007.1.31 Revision(s)
1. Resolves of all known permissions issues under Windows Vista.
2006.11.1 Revision(s)
1. TztvFindFile: wasn't returning file found results when the conditional
define TNT_UNICODE wasn't used. Fixed.
2. Revisit of Windows Vista permissions issue. If you come across any
drive or directory permissions issues, please report them and we'll
make the correction and send the revision to you via email. Any
permissions failures should route a E_PERMISSIONS error code (see
err_msgs.rc and err_msgs.pas) to the OnError event handler.
2006.10.26 Revision(s)
1. TZipSplitGlue: wasn't recognizing archives of type atZipMV.
2. Attempting to create an archive to a directory where user does not have
permission rights now handled correctly.
3. Compressors: storing empty directory names to an archive were failing
when the Windows Indexing Service was turned off.
2006.10.1 Revision(s)
1. IMPORTANT installation and distribution notes: (please read carefully):
a. two dll filenames have changed: TUnAce requires ztvUnace26.dll and
TUnRar requires ztvUnRar36.dll. You will have to make the necessary
revisions to your distributable application to reflect the correct
support files.
b. The following mentioned unicode support requires the source code
version, since the code needs to be recompiled using the TNT_UNICODE
conditional define to include widechar support.
c. UNICODE VERSION: ALL projects require a conditional define:
"TNT_UNICODE" (without the quotes). This includes all demos included
in the package for unicode / dbcs support. Unicode support is optional.
d. Installation of this package requires a 3rd party component package
(freeware)...the Tnt Unicode Controls (version 2.2.8). It can be
downloaded from the following location:
http://www.tntware.com/delphicontrols/unicode/.
** Unicode support is optional **
2. Source version only: all directory and filename strings have been converted
to WideStrings for support of DBCS and other languages not displayable under
various codepages. In ZipTV with unicode, these strings can be monitored
using unicode compatible functions. Languages tested include Russian,
Russian Cyrillic, Chinese, Japanese, Thai, Arabic (right to left ordering),
Czech, Danish, French, Korean, and Greek.
3. Unicode and DBCS support requires Delphi 6+. The Win95, Win98, and WinME
operating systems require the Microsoft Layer for Unicode. For further
information about the MSLU see:
http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx.
4. Tested and verified compatibility with Japanese versions of Windows.
5. In this version, we've gone back to the drawing board. We tested and
retested thousands of archives, updating many algorithms to correct
any inconsistencies that may have been introduced over a period of
years through simple revisions and the introduction of new components
to the suite.
6. Security update patch. For further information see:
http://www.securityfocus.com/bid/19884/references
2006.1.26 Revision(s)
1. TArchiveStream: this revision deals with the .cab and .rar formats.
Their respective dll api's require their functions open the archive
from disk. This requirement prevents sending the decompress components
for these types an untyped stream as an archive. We included a
workaround for these archives which flushes the untyped stream to a
temporary file in the (windows temp dir) and using this temp file as
the input stream.
2006.1.16 Revision(s)
1. TZipRun upgraded. Click here for more details.
2. TZipTV: after adding AES encryption to the .bh (TBlakHole) compression,
TZipTV was returning "Unsupported" compression algorithm. This did not
affect compression or decompression of .bh files.
2006.1 Revision(s)
1. Included support for C++ Builder 2006.
2005.6.4 Revision(s)
1. TUnCab (sfx's): installed routine to revise the offset of the compressed
data for sfx archives.
2005.6.3 Revision(s)
1. New component: TZipTV_Stream. Similar to the TZipTV component for reading
an archive's contents, but different in that an archive contents is saved
to a stream. Several methods have been included for reading the contents
stream.
2005.5.6.1 Revision(s)
1. TBlakHole & TUnBh: included support for the BZip2 compression algorithm.
2005.5.0 Revision(s)
1. New components: TTarGZ and TTarBZ. Compressors components that first create
.tar archive, then compress the resulting archive into a .tgz or .tbz
archive. A .tgz archive can be decompressed using the TUnGZip and TUnTar
components. A .tbz archive can be decompressed using the TUnBZip and TUnTar
components.
2005.4.0 Revision(s)
1. Maintenance release
2005.3.0 Revision(s)
1. TZipTV: OnRead event: Offset parameter changed from type Integer to Int64
in support of files > 4 gig.
2. TZipSplitter & TArchiveSplitter. Completed support for archives larger
than 4 GB
2005.2.1 Revision(s)
1. Maintenance release
2005.2.0 Revision(s)
1. New component (beta): TArchiveStream. Unit(s): ztvArchiveStream.pas. The
operation of TArchiveStream is to decompress files within an Archive
irregardless of the origin of the stream or it's type.
Since there are many development implications with this component
(internet/intranet streaming, port streaming, raw decompressed data handling
(data searches, virus scanning, etc) supporting multiple archive types,
we've developed this component with close adherence to the KISS principle,
thus providing the functionality with maximum flexibility.
2005.1.0 Revision(s)
1. TBZip & TUnBZip components added to component suite.
2. TZipSplitter, TZip, TUnZip: files can now be compressed to .zip files
using the BZip2 compression algorithm.
2005.0.2 Revision(s)
1. Added support for Delphi 2005.
2. TZipTV & TUnTar: Included support for tar filenames greater than
the header limitation of 100 chars.
3. Filenames for the 3 dll's that we support have changed. The new dll's
names now start with 'ztv'. ztvunrar3.dll, ztvcabinet.dll, ztvunace2.dll.
7.4 Revision(s)
1. Added support for a WinXP limited user account. When attempting to extract
to a directory the user does not have permissions for, a new OnLimitedUser
event is activated. This event passes both the name of the protected
directory and the users directory. Users directories are located off
"documents and settings" and are generally the only directory that holds
write protections for these user accounts.
7.3 Revision(s)
(beta due to ZipV2 encryption SeedKeys). Beta additions subject to change
without prior notice.
1. WinZip "v9 final" bug: in multiple disk spanned archives, the PackedSize
variable field is not assigned a value in the LocalHeader of each
compressed file that spans two or more diskettes. We've included a
workaround for this bug, but will not include workarounds for bugs found
in their application in the future.
7.2 Revision(s)
1. ZipV2 (zip version 2+) encryption now supports the revision of the three
previously constant seed-keys. These three keys have been hard coded in
every application supporting zip password encryption for decades,
leaving encrypted files vulnerable to the brute force hack attack.
Revising the value of these keys make the original zip encryption the
absolute most secure method of protecting compressed archives with a
password (even the new AES algorithm is vulnerable to the brute force attack).
2. Decompressors -> "OnGetPassword" event change:
Old:
TOnGetPassword =
Procedure(Sender: TObject; FileName: AnsiString; Var Password: AnsiString;
Var TryAgain: Boolean) Of Object;
New:
TOnGetPassword =
Procedure(Sender: TObject; FileName: AnsiString; Var Password: AnsiString;
Var HeaderKeys, DataKeys: TSeedKeyValues; Var TryAgain: Boolean) Of Object;
3. New properties:
a. SeedHeaderKeys (TZip, TJar, TBlakHole, TZipSplitter, TZipTV, TUnZip, TUnJar,
TUnBh TZipSearch TZipCheck, TZipRun components)
b. SeedDataKeys (TZip, TJar, TBlakHole, TUnZip, TUnJar, TUnBh, TZipSearch,
TZipCheck, TZipRun)
Both properties are of type TSeedKeys (defined in ztvCrypt.pas - requires source
version to see).
Type
TSeedKeyType = (skDataKeys, skHeaderKeys);
TSeedKeys = Class(TPersistent)
Private
SeedKeyType: TSeedKeyType;
Function GetKeyValue(x: Integer): Cardinal;
Function GetDefaultKeyValue(x: Integer): Cardinal;
Procedure SetKeyValue(x: Integer; Value: Cardinal);
Protected
Public
Constructor Create(sk: TSeedKeyType); Virtual;
Procedure SetKeys(k0, k1, k2: String); Overload;
Procedure SetKeys(k0, k1, k2: Cardinal); Overload;
Procedure SetDefaultKeys;
Property GetDefaultKey[x: Integer]: Cardinal Read GetDefaultKeyValue;
Property Key[x: Integer]: Cardinal Read GetKeyValue Write SetKeyValue;
Published
Property Key0: Cardinal Index 0 Read GetKeyValue Write SetKeyValue;
Property Key1: Cardinal Index 1 Read GetKeyValue Write SetKeyValue;
Property Key2: Cardinal Index 2 Read GetKeyValue Write SetKeyValue;
End;
4. New boolean method: IsSeedKeysSupported(TArcType);
Not all decompressors contain the above Seed[..]Keys properties. It is
good practice to always verify support with the component in use, prior
to their use. Improper use of either of these two properties with a
component which does not support them will result in an exception being
raised.
Example: If IsSeedKeysSupported(UnZip1.ArcType) Then ...
Note(s):
a. The ZipV2 encryption algorithm has always been a rock solid encryption
method for archives since it's introduction into the original Pkzip v2.0
DOS archive application. Since it's inclusion, there have been 3 seed-key
values hard coded into every zip application whose values are:
Key 0: 305419896
Key 1: 591751049
Key 2: 878082192
These values are hard coded into every application supporting the zip
archive format and password encryption. These three keys are the only
reason the Zipv2 encryption algorithm was open to the brute force hack
attack. Consider our findings with the use of the TZipKey component:
# |------ Possible combinations -------|
CharSets property Char set chars with 4 char pwrd with 5 char pwrd
--------------------------------------------------------------------------------
csNumeric | 0..9 -> 10 | 10,000 | 100,000 |
csAlphaUpperCase | A..Z -> 26 | 456,976 | 11,881,376 |
csAlphaLowerCase | a..z -> 26 | 456,976 | 11,881,376 |
csAlphaULcase | a..Z -> 52 | 7,311,616 | 380,204,032 |
csAlphaNumeric | 0..10, a..Z -> 62 | 14,776,336 | 916,132,832 |
csAlphaNumericU | 0..10, A..Z -> 36 | 1,679,616 | 60,466,176 |
csAlphaNumericL | 0..10, a..z -> 36 | 1,679,616 | 60,466,176 |
csFullSet | 0..255 -> 256 | 4,228,250,625 | 1,078,203,909,375 |
csNonAlphaNumeric | -> 193 | 1,387,488,001 | 267,785,184,193 |
--------------------------------------------------------------------------------
Note the csFullSet (using upper/lower case, and numeric chars) line
with a 5 char password. There are over 1 trillion, 78 billion possible
combinations of 5 chars which could possibly be the password! Even with
today's computers, it could take weeks or even months (never could wait
long enough really for a conclusive time) for a computer doing nothing but
scanning possible combinations to compromise a simple 5 char password.
This also is using the hard coded three seed-keys mentioned above. Now,
consider changing the seed-keys, using the same csFullSet, 5 char password.
The possible combinations are OFF THE CHART. Before we can begin a brute
force search for the characters in the password, we must have the encrypting
seed-keys values... possible key value combinations: 4294967295 *
(4294967295 * 4294967295). Not likely without first hand knowledge of the
key values. The possible combinations for the password are now ((4294967295 *
(4294967295 * 4294967295)) * 1,078,203,909,375). Not totally impossible, but
with numbers that huge, what is the probability?
I wrote the TZipKey component several years ago (a brute force encryption
attack) as a method of retrieving lost or forgotten passwords. It's the most
widely known password attack against zip encrypted archives known (to date,
I know of no one that has come up with a better or faster method of archive
password retrieval). As a test of the AES encryption algorithm, I recently
updated the TZipKey component to include the AES algorithm (not for
distribution... don't ask) . The AES encryption method has recently been
selected as the most secure data encryption method currently in use, but it
was just as vulnerable to the brute force attack as the original zipv2
algorithm was...with the exact findings as the above chart for the zipv2
algorithm It is my opinion that the most secure method of archive encryption
is the revision of the previously hard coded constant seed-keys. Study the
algorithm... it's simply irreversible... can't be done... impossible. The
only hole (a very small hole I might add) in the zipv2 encryption algorithm
was the hard coding of the 3 seed-keys.
The use of, and security of Seed-Keys:
The use of unique seed keys does come with a cost. Revise a seed-key,
password protect compressed files, lose the seed-key values the files were
encrypted with... there is absolutely no way to decrypt and decompress the
archive. The data is simply lost. Is this heightened level of security worth
the cost? The US Military thinks so. They have been using seed-keys for
encrypting classified and top secret data and communications for decades.
Unique seed-keys in encryption is at the top of the chain for data security.
Even if your company's unique keys were to be compromised, your back to a
pretty good level of security the original zipv2 encryption afforded you...
approx 95-99.9% depending on the number and mixture of chars used in the
password.
5. TArc2Arc: ztv[..].tmp files containing the read-only file attribute were not
being deleted during cleanup.
6. Compress disk-spanning: the OnClearDisk event was revised to activate every time
when FreeSpace < TotalSpace.
7. Support for extraction of files from .cab sfx's (self extractable). ArcType =
atCabExe.
8. TArc2Arc:
a. temp files, created from compressed files containing the hidden file-attribute
were not being cleaned up (deleted) when TArc2Arc finishes it's task.
Corrected.
b. added support for ArcType = atCabExe
9. Revised TFileScan to include support for filenames beginning with the '.' char.
I.e., ".testing".
7.1.3 Revision(s)
1. TArchiveEditor: previous versions were unable to correctly edit archives created
using pkzip v2. Corrected
7.1.2 Revision(s)
1. TZipRun Component: added OpenWith property.
TOpenWith = (omRegistryAssoc, omCmdLine, omOpenWith);
a) omRegistryAssoc: extracts and runs the specified file using extension
associations in the registry.
b) omCmdLine: extracts and runs the specified file allowing the user to specify
a specific application to run the extracted file via command line.
c) omOpenWith: displays the OpenWith dialog for the user to select an application
to run the extracted file.
7.1.1 Revision(s)
1. ztvGbls.pas: Added atB64 to TArcType for support of Base64 decoding.
2. ztvConsts.pas: Added the .mim extension to ExtArray for support of Base64
registry association.
3. TRegArchive (ArcExtensions property): in the Delphi object inspector, either
add the .mim extension, or clear all default extensions from this property.
The next time your project is run, the .mim extension will be automatically
added to this property, and registry associations for this extension will
be supported.
4. We're in the beginning stage of supporting double-byte and unicode char sets.
If you use any of the following functions in your projects, add an preceding
underscore to the function name. There may be some name changes that aren't
listed. If looking for a function that was in a previous version, none have
been removed... just postfix an underscore to the name:
AppendDirTail -> _AppendDirTail
GetFileType -> _GetFileType
EraseFile -> _EraseFile
ChangeFileExt -> _ChangeFileExt
ztvFileExists -> _FileExists
7.1.0 Revision(s)
1. The ArchiveComment comment was changed to a stream object
(ztvStreams.TCommentStream). It is now much easier to view & edit the
archive main comment.
2. SetComment method changed to SetFileComment (differenciate between a file
and archive's main comments).
3. GetComment method changed to GetFileComment (differenciate between a file
and archive's main comments).
7.0.8 Revision(s)
1. Compress Components - StoreDirNames property:
Affects:
StoredDirNames = sdExplorer_Auto or
StoredDirNames = sdExplorer_UserDefineDefaultDir
Compression component's property values for testing:
[CompressComponent].StoredDirNames = sdExplorer_UserDefineDefaultDir;
[CompressComponent].RecurseDirs := False;
[CompressComponent].DefaultDir := 'D:\12test\Sub1\;
Using the following batch file content (test.bat) create the following
directory / file structure for testing:
mkdir d:\12test
mkdir d:\12test\Sub1
echo "aaa" > d:\12test\Sub1\test1.txt
echo "aaa" > d:\12test\Sub1\test2.txt
mkdir d:\12test\Sub1\Sub2
echo "aaa" > d:\12test\Sub1\Sub2\test3.txt
echo "aaa" > d:\12test\Sub1\Sub2\test4.txt
The resulting file structure will be:
D:\12test\Sub1\Test1.txt
D:\12test\Sub1\Test2.txt
D:\12test\Sub1\Sub2\Test3.txt
D:\12test\Sub1\Sub2\Test4.txt
Value of the FileSpec property (same as the above dir structure):
D:\12test\Sub1\test1.txt
D:\12test\Sub1\test2.txt
D:\12test\Sub1\Sub2\test3.txt
D:\12test\Sub1\Sub2\test4.txt
Previous versions: stored structure in the resulting archive was:
Test1.txt
Test2.txt
D:\12test\Sub1\Sub2\Test3.txt
D:\12test\Sub1\Sub2\Test4.txt
Current version: stored structure in resulting archive is:
Test1.txt
Test2.txt
Sub2\Test3.txt
Sub2\Test4.txt
Note(s)
1. Notice the Sub2\Test3.txt and Sub2\Test4.txt names stored in the
archive are sub-directories of the value assigned to the DefaultDir
property above ('D:\12test\Sub1\').
2. The use of the sdExplorer_UserDefineDefaultDir setting requires
assigning the DefaultDir property a valid existing directory name.
7.0.7 Revision(s)
1. AES (block cipher Rijndael) encryption revisited.
7.0.6 Revision(s)
1. TUUEncode and TUUDecode.pas: added Base64 encoding/decoding.
7.0.5 Revision(s)
1. Bug found in the extraction of AES encoded "stored" (no compression)
files. Fixed.
7.0.4 Revision(s)
1. [Compress Component].StoredDirNames property: UserDefineDefaultDir
changed from case sensitive to case insensitive.
Example:
The following would fail due to case sensitivity.
ZipSplit1.DefaultDir := 'E:\';
ZipSplit1.FileSpec.Clear(); ZipSplit1.FileSpec.Add('e:\test\*.*');
ZipSplit1.Compress();
2. [Compress Component].ExcludeSpec property: this property no longer
requires a fully qualified path.
Example:
ZipSplit1.FileSpec.Clear();
ZipSplit1.FileSpec.Add('e:\temp10\*.*');
ZipSplit1.ExcludeSpec.Clear();
ZipSplit1.ExcludeSpec.Add('cache\*.*');
ZipSplit1.RecurseDirs := True;
ZipSplit1.DefaultDir := 'e:\';
ZipSplit1.StoredDirNames := sdExplorer_UserDefineDefaultDir;
ZipSplit1.Compress();
e:\temp10\cache: cache is a sub-directory of e:\temp10.
Previous versions of ZipTV required the ExcludeSpec property to contain
the fully qualified path e:\temp10\cache in order to exclude files from
this directory. Note in the above example that 'cache\*.*' is not
allowed. However, it must be a subdirectory of one of the strings
defined in the FileSpec property.
7.0.3 Revision(s)
1. TUnRar: bug developed in v7.0.2 due edits done in that version.
7.0.2 Revision(s)
1. TUnGzip: updated to support unix created multi-header compressed .gz
archives. Don't confuse this with multi-file. The .gz format is still
a single file compressor, but some versions of the UNIX / LYNIX gzip
utility, the compressed data stream is broken into multiple segments
and separated by these headers.
Example test files:
http://www.ziptv.com/TestFiles/gc5.0alpha3.tar.gz
http://www.ziptv.com/TestFiles/old_access_log.2000Aug.gz
http://www.ziptv.com/TestFiles/old_access_log.2001Jan.gz
http://www.ziptv.com/TestFiles/old_access_log.2002Apr.gz
7.0.1 Revision(s)
1. TZip, TUnZip, TZipSplitter, TJar, TUnJar Components:
a) added the much requested AES (block cipher Rijndael) encryption.
The zip AES standard is now based on Dr. Brian Gladman's implemen-
tation of the Rijndael algorithm.
2. TZip, TZipSplitter, TJar:
a) ztvBase.pas new property: TZipCommon.GetEncryptionMethod():
TEncryptionMethod.
Returns one of the following TEncryptionMethod members:
TEncryptionMethod = (emNone, emAES2_ 1 28, emAES2_ 1 92, emAES2_256,
emZIP_v2, emUnsupported);
b) EncryptionMethodStr (ztvGbls.pas). Returns the string equalivant of
the above TEncryptionMethod.
3. Linking ZipTV AES into the ZipTV Components:
In BCB's project options, set the conditional define as MCSREG. In the
source version, failure to follow this step will result a failure to
compile with error message "[Fatal Error] ztvBase.pas: Unit ztvRegister
was compiled with a different version of ztvBase.TZipCommon.
NOTE(s)
* The sources for AES encryption are not yet available.
* Our AES implementation require no external dll's!
6.8.4 Revision(s)
1. All compress components - OnDeleteFile Event
a) the value of this event's "count" parameter (count of files deleted.
including the current file) started at 0 instead of 1. Fixed.
b) when the value of the Switch property is "swMove" and the file
already exists in the archive, the file was not deleted from disk.
Fixed.
6.8.3 Revision(s)
1. TUUEncode & TUUDecode
Updated for compatibility with .zip multi-volume archives.
2. All compression components -- VerifyBeforeDelete property
When the Switch property equals swMove and the VerifyBeforeDelete
boolean property was true (default = false), files were properly added
to the archive, but not deleted from disk.
6.8.2 Revision(s)
.zip disk-spanning bug fix.
6.8.1 Revision(s)
Decompression components - ExtractToFileStream method bug fix
6.8.0 Revision(s)
This revision changes some event parameters! Please read!
When loading projects developed under previous versions, BCB will report
these event changes and request to remove the reference to the event.
When loading a project in this version and Delphi reports these event errors:
a) Write down the component and event names so you can re-install the code
from the old, to the new event handler.
b) Let Delphi remove the reference.
After the project is loaded:
a) Delete the event defination (but not the event handler - containing the
event's code).
b) In the object inspector, double click on the event name (BCB should have
already removed the reference, so it should be blank).
c) Copy your code from the old to the new event handler.
d) Delete the old event handler (including the code you've copied to the
new handler).
e) Inspect the new event handler for changes which may affect the code you
have copied to the new handler.
1. TRegArchive Component - OnAssociation event.
Parameter revision:
Old declaration:
TOnAssociation = Procedure(Sender: TObject; Appname: String)
Of Object;
New declaration:
TOnAssociation = Procedure(Sender: TObject; Appname: String;
Var Cancel: Boolean) Of Object;
Previous versions:
This event was activated if the ActivateOnStartup property was true.
When true, during application startup, this event activated. Within
this event, the "install method" would be assigned to install the file
extension associations into the registry. In this version, a cancel
method was installed to the OnAssociation event. If cancel is true
(default), the install method will not be called internally, and the
association process is canceled.
This version:
The OnAssociation event MUST be set and the value of the "cancel"
parameter must be false, for user confirmation of the registry
association edits. If it is not set, and the cancel parameter is true
(default) no file associations in the registry will take place.
DO NOT CALL THE "INSTALL METHOD" FROM WITHIN THIS EVENT. SET ONLY THE
CANCEL PARAMETER TO FALSE, IF REGISTRY ASSOCIATIONS ARE TO TAKE PLACE.
2: TRegArchive Component - Install method
The "install method" is now a function of type ShortInt, returning the
following result codes:
raComponentState = ComponentState is in csDesigning mode
raCancel = OnAssociation's "cancel" boolean parameter was true (default)
raOnAssociation = OnAssociation event was not set
raOk = associations was written to registry
raNoneRequired = no associations were required (already associated)
3: TZipTV, TZipRun, all decompression components
Added property ExcludeSpec
Added event OnExcludeFile
This property and event has always been present in the compressor
components, now added to the above mentioned components. Their
function is to narrow the specification of files for processing in
conjunction with the FileSpec property.
Using the decompressor components as an example, the FileSpec property
might contain the wildcard '*.*' (which means to include all files for
processing). The ExcludeSpec property is assigned the wildcard '*.txt'
which means to exclude all files for processing which has the .txt file
extension.
The OnExcludeFile event is activated once for eah file found to match
the FileSpec specification, but is in the list of files to be excluded.
4. TArchiveEditor Component - OnBatchSkipFile event
Parameter revision:
Old declaration:
TOnBatchSkipFile = Procedure(Sender: TObject; NewFileName: String;
Index: Integer; Var SkipChange: Boolean) Of Object;
New declaration:
TOnBatchSkipFile = Procedure(Sender: TObject; OldFileName,
NewFileName: String; Index: Integer; Var SkipChange: Boolean) Of Object;
The original name of the compressed file (OldFileName) was also
necessary to better determine which file names to skip revisions.
5. ztvInflate.pas and ztvDeflate.pas
ztvInflate.ztvDecompress_StreamToStream revised
ztvDeflate.ztvCompress_StreamToStream revised
6. TZipSplitter Component - OnSplitEnd event
Parameter revision:
Old declaration:
TOnSplitEnd = Procedure(Sender: TObject) Of Object;
New declaration:
TOnSplitEnd = Procedure(Sender: TObject; VolumesCreated: Cardinal) Of Object;
6.7.1 Revision(s)
TOnNextVolume event: changed parameter VolumeID from data type
AnsiString to Integer.
Old declaration:
TOnNextVolume = Procedure(Sender: TObject; Var VolumeName: AnsiString;
VolumeID: AnsiString; fExists: Boolean; Var Cancel: Boolean) Of Object;
New declaration:
TOnNextVolume = Procedure(Sender: TObject; Var VolumeName: AnsiString;
VolumeID: Integer; fExists: Boolean; Var Cancel: Boolean) Of Object;
6.7.0 Revision(s)
New component: use TZipSplitGlue, combine a multi-volume .zip achive into a
single (non-volume) output .zip archive.
6.5.5 Revision(s)
1. TUnZip: disk-spanning bug arose during development of TarchiveSplitter
and TZipSplitter components. Fixed.
6.5.3-4 Revision(s)
1. Delphi revisions only
6.5.2 Revision(s)
1. All compressor components OnStoreFilesOfType property:
a) On creation of a compressor component, this TStrings property was
incorrectly inserting a blank line, resulting in files without
extensions to be stored in an archive with no compression.
b) If this property was set in Delphi's object inspector, an exception
will raise.
c) If this property wasn't set in Delphi's object inspector, the problem
will not show.
6.5.1 Revision(s)
1. TZipSplitter: added support for the CompressionMethod property
(supported by all other compressors). Prior versions could not
successfully compile zip archives with CompressionMethod = cmInMemory.
There are two possible settings for ths property, cmTempFile and
cmInMemory.
August 29, 2003 - 6.5.0 Revision(s)
1. TZipSplitter: this is the first version where this component can
actually and reliably replace the TZip component. It has the ability
to add and delete files from multi-volume zip files.
2. Messages passed to the OnError event were updated.
3. TArchiveEditor: bug found and fixed when editing .tar file filenames
and dates.
4. TUUEncode and TUUDecode : bug found and fixed.
5. TZipKey : bug found and fixed.
Note 1: The secret to TZipSplitter is it’s OnSplitBegin event. When this
event handler is activated, a form can be displayed, requesting
volume size (no volume split is an option) number of output
volumes etc. TArchiveSplitter and TZipSplitter do not at this time
support files greater than 4 gig. If this feature is required,
use the TZip component.
Note 2: To enable debug of ZipTV, change the following line in ziptv.inc
unit: {.$define ENABLE_DEBUG} to {$define ENABLE_DEBUG} (dot
before $define removed)
Note 3: Zip volumes created using TArchiveSplitter and TZipSplitter are
compatible with volumes created by WinZip. ZipTV takes zip split
volumes a step further in the ability to split zip volumes during
the creation of an archive. Not available in any other archive
format is the ability to add and delete files from volume
archives (TZipSplitter).
Note 4: Projects developed with the registered version of ZipTV must
always be compiled using MCSREG as a conditional define. This
conditional isn’t mandatory in the current release, but will
be so in future versions.
6.4.1 Revision(s)
1. TArchiveSplitter and TZipSplitter upgrade
2. Some constants were moved from various units to the ztvConsts.pas
unit. If you encounter a "undeclared identifier" error, add ztvConsts
to that units uses clause.
3. Error reported editing zip archive and file comments. Fixed.
6.4.0 Revision(s)
1. Maintenance release.
July 14, 2003 - 6.3.2 Revision(s)
1. TZipSplitter: merged into parent objects for basic usage simularity with
other compressor components.
2. TZipTV and TUnZip updated for compatibility with WinZip 9.0 support of
unlimited sized archives.
3. Bug fix: v6.3.1 introduced a compatibility issue with Win9x OS's. We
used a function to handle the compressed output temp file which was not
compatible with Win9x. Fixed.
June 9, 2003 - 6.3.1 Revision(s)
1. Bug created in the May 29th release. Procedure
TZipCommon.TempFileMoveFile(...) (in ztvBase.pas) was added for seamless
handling of moving of the created temp file with all compressors. When
attempting to create archives on seperate fixed drives, the temp file
was not moved. Fixed.
May 29, 2003 - 6.3.1 Revision(s)
1. TArchiveEditor: we've spent alot of time on the update of this
component. It is no longer being considered beta.
May 2003 - 6.3.0 Revision(s)
1. TUnAce: when renaming extracted files (via the OnRename event),
directories contained in the unrenamed file were created.
2. TZipTV: updated to support unicode rar filenames.
3. TUnRar: updated for proper extraction of unicoded filenames.
4. TArcSplitter: internal properties were updated to interact with other
related properties. The revision greatly reduces the number of improper
set property values.
April 29, 2003 - 6.2.0 Revision(s)
1. In version 6.1.1 we revised the ExtractDir property to default to the
path where the extracting archive resides. This change was implemented
to account for a blank value of ExtractDir. However, it created a bug
in the TArc2Arc component.
April 14, 2003 - 6.1.1 Revision(s)
1. ZipTV supports the extraction of specific files even from split .zip
archives.
April 1, 2003 - 6.1.0 Revision(s)
1. When attempting to compress archives to diskette which do not support
disk-spanning, a disk-full error is now routed through the OnError event.
2. Compression Components: if the values of TempDir property and ArchiveFile
property are located on the same drive, a FileMove is involked to move
the temporary output file, instead of a stream copy. This increases
completion speed dramatically.
3. TArchiveSplitter: the remaining issue with this new component was
resolved. If the size of the central directory exceeds the desired output
volume size, the central directory is now split correctly between multiple
output volumes.
4. Decompression Components: OnRenameFile event added.
5. All components (ztvFileIo.pas): ArchiveDate (or fArchiveDate in some
versions) reported time in UTC instead of local time.
February 25, 2003 - 6.0.0 Revision(s)
1. New component: TArchiveSplitter. Starting with v5.2, TZipTV & TUnZip
supported split archives created under WinZip. This new component now
includes support for the creation of these archives.
2. All components were edited for enhanced streaming support. ZipTV now
supports compression / decompression to and from the clipboard, strings,
buffers, etc. This support opens a wide range of usage for our components.
February 4, 2003 - 5.6.2 Revision(s)
1. Added support for .war archives. For more info on the .war format see
http://java.sun.com/webservices/docs/1.0/tutorial/doc/WebApp3.html
February 3, 2003 - 5.6.1 Revision(s)
1. Added ability to read and display (TZipTV) .cab sfx (executable)
archives as well as the ability to extract (TUnCab) compressed files
within these sfx's.
January 31, 2003 - 5.6 Revision(s)
1. TRegArchive: when running an application through a network, the
computer name and drive was being improperly written to the reigstry
when associating archive extensions to the application.
January 29, 2003 - 5.5 Revision(s)
1. TZipTV and TUnRar: updated these two components to handle .rar
archives whose compressed and/or uncompressed file sizes exceed the
4 gig barrier.
January 24, 2003 - 5.4 Revision(s)
1. Compression Components (Attributes and AttributesEx properties): added
support for the FILE_ATTRIBUTE_NOT_CONTENT_INDEXED and
FILE_ATTRIBUTE_ENCRYPTED file attributes.
2. TUnAce: rewrite of this component for better handling of the extraction
of specific (selected) files within an .ace archive.
3. TZipTV and TUnArj: added a 5000k buffer to search deeper into a file
for the .arj archive signature, allowing a more precise identification
of an .arj archive.
November 1, 2002 - 5.3 Revision(s)
1. TZip, TUnZip, TZipTV: added support for compression of files with sizes
greater than 4gb on NTFS formated drives. This revision will require
the following revisions to projects developed with prior versions:
Event: OnFileScanStatus
Parameter: FilesSize changed from type double to int64
Components effected: TZip, TBlakHole, TGZip, TTar, TMakeCab, TJar, TLha
Event: OnTotals
Parameter: UnpackedSize and PackedSize changed from type double to int64
Components effected: TZipTV
October 1, 2002 - 5.2 Revision(s)
1. Added support for WinZip's split volume archives. This version supports
the viewing and decompression of multi-volume zip archives, the next
revision will include the new component TArchiveSplitter which will
support the compression of compatible multi-volume split zip archives.
July 5, 2002 - 5.0 Revision(s)
1. Deflate64 method now supported
June 21, 2002 - 4.8.6 Revision(s)
1. All components interacting with SFX archives have been updated for the
current ztv_*.sfx stub files. These components (all decompression
components, TZipTV, TMakeSfx, TUnSfx) were updated also to include SFX
archives created by a greater number of non-ZipTV SFX archives.
2. Archive detection routines updated for smoother interaction between
components.
Be sure to download version 4.8.6 of the ZipTV sfx-stub files!
June 8, 2002 - 4.8.5 Revision(s)
1. ztv_lha.sfx: upgraded for support of the Frozen7 compression method.
2. TMakeSfx & TUnSfx: updated for compatibility with the latest
sfx-stub files.
June 3, 2002 - 4.8.4 Revision(s)
1. ztv_ace.sfx: upgraded for support of the ace version 2 archive format.
Requires unacev2.dll from the ZipTV Compression Components (installs
in your system dir when ZipTV is installed).
2. ztv_rar.sfx: upgrade for support of the rar version 3 archive format.
Requires unrar3.dll from the ZipTV Compression Components (installs
in your system dir when ZipTV is installed).
3. TZipTV, TUnAce, TUnRar: upgraded for support of the above two sfx
(executable) archives. These components can read, list, and extract
these new executable archives.
4. TUnLha: upgraded for support of the latest compression algorithm
(frozen7).
May 13, 2002 - 4.8.3 Revision(s)
1. small fix to the decompressor component's OnRecurseDirs property.
May 8, 2002 - 4.8.2 Revision(s)
1. Maintenance release.
2. First version for Borland C++ Builder 6!
April 13, 2002 - 4.8 Revision(s)
1. TArchiveEditor: new "beta" component. Edit an archive's compressed
filenames, dates, and file-attributes.
April 7, 2002 - 4.7.1 Revision(s)
1. TUnCab: modifications by the brilliant mathematician and programmer,
Alexey Chernobaev, to support the proper handling of nested .cab files
(archive within archive).
2. TArc2Arc: upgraded to include support of proper conversion of many
archive types to a .tar.gz arhive.
March 21, 2002 - 4.6.8 Revision(s)
1. Compression Components (TJar, TZip, TBlakHole, TLha): added property
StoreFilesOfType property. Add extensions (including the dot char '.'),
of file-types to store into the archive, instead of using compression.
For example, to store an already compressed .zip archive into another
archive (instead of attempting to compress it again) add the extension
.zip to this property.
2. StoreAlreadyCompressedFiles property removed. With the addition of the
StoreFilesOfType property, this property is now obsolete.
3. TStoredDirNames:
a. renamed set member sdExplorer as sdExplorer_Auto. Use this member
to add multiple FileSpecs from multiple directories. Any prior
setting of the DefaultDir property is ignored, and is set
automatically according the what directory is common to all
FileSpecs.
b. Added member sdExplorer_UserDefineDefaultDir.
sdExplorer_UserDefineDefaultDir requires the setting of DefaultDir
as the rootdir prior to calling the Compress() method. For example,
if you dropped files from the Windows Explorer, from directory
c:\windows\system, set the DefaultDir property as 'c:\windows\
system'. The dropped files directories will be stored into the
archive accordingly.
February 16, 2002 - 4.6.5 Revision(s)
1. TUnRar: added support for extraction of split files from diskettes.
February 14, 2002 - 4.6.4 Revision(s)
1. TUnRar: added support for RAR split files (filename.part1.rar,
filename.part2.rar, filename.part3.rar, etc.). Old multi-volume naming
convention is still supported (filename.rar, filename.r00, filename.r01,
etc.).
2. TZipRun: added OnNextVolume event for support of the new RAR split-file
/ multi-volume support.
3. TZipTV: revised to support RAR split-files.
February 12, 2002 - 4.6.3 Revision(s)
1. TZip / TUnZip: EncryptHeaders property. Foriegn characters in filenames
were not being property restored when the EncryptHeaders property was
true.
2. TTar: progress bar was not being updated properly when adding "huge"
files to a .tar file.
February 6, 2002 - 4.6.1 Revision(s)
1. TZip / TUnZip: installation of function to properly handle foreign
char sets.
February 5, 2002 - 4.6.0 Revision(s)
1. TUnRar: included main archive comment and password protected archive
support. This component, recently upgraded for compatibility with the
new .rar v3.0 format, is now complete.
2. TUnRar: renamed unrar.dll to unrar3.dll for version identification
purposes.
January 31, 2002 - 4.5.5 Revision(s)
1. TZip / TUnZip (EncryptHeaders property): a routine which handles a #0
char (end_of_string) in foreign chars sets, was interfering with the
compressed filename encryption routine. Encrypted filenames sometimes
contains this char... when altered for foreign char sets, naturally the
decryption function was not returning the proper decrypted filename.
January 28, 2002 - 4.5.4 Revision(s)
1. TUnRar: bug fix created in 4.5.3 revision which prevented extraction of
compressed .rar files from readonly drives, such as a cd rom.
2. TUnRar: installed error handler for .rar "broken archive". Previous
version terminated with no error reported.
January 25, 2002 - 4.5.3 Revision(s)
1. Updated TUnRar for compatibility with the new v3 rar format.
January 24, 2002 - 4.5.2 Revision(s)
1. Bug found in WinZip with regard to crc calculation of .zip archive
"stored" files. Adjustment made to compensate for this bug so the TZip
component is compatibility with WinZip's stored files.
January 23, 2002 - 4.5.1 Revision(s)
1. Installation of all .zip diskette spanning functions into v4 series
(moved over from v3.x) now complete.
2. Fix with regard to network unc-pathnames.
January 21, 2002 - 4.5.0 Revision(s)
Maintenance release
January 16, 2002 - 4.4.0 Revision(s)
1. New streaming methods installed which improves compression speed even
further. Test results compressing a 2 gigabyte text file using WinZip
= 14 minutes, ZipTV = 7.4 minutes.
2. New .ace format updates. Multi-volume archive updates.
3. Diskette-spanning updates.
4. Addition of huge archive compression / decompression support.
October 15, 2001 - 4.1.9 Revision(s)
1. Removed limitation regarding compatibility with other utilities (such as
WinZip) in the downloadable shareware version. Shareware version now
creates compatible archives.
2. This will be the last update for the downloadable shareware version in
the version 4 series. Updates will continue with the registered version.
October 14, 2001 - 4.1.8 Revision(s)
1. Beta status removed... help file still requires updating.
2. StoredDirNames (sdExplorer set member): updated for better drop / drag
operations.
3. TMakeSfx: updated for compatibility with sfx stubs.
