wtfbbqhax/ziptool

Automatically exported from code.google.com/p/ziptool

ziptool's Issues

ZIPTool 2.1.0 does not properly exit on the invalidation of the pure archive

Problem:

exit( 1 ); was missed for the ValidateArchiveCompatibility() when checking the 
pure archive.


This should be a relatively minimal problem as this archive is opened read only 
and the post processing will probably fail somewhere in the central directory 
traversal code, but it still needs to be fixed.

Original issue reported on code.google.com by [email protected] on 11 Feb 2011 at 2:51

ZIPTool 2.0.0 Code Needs to be Refactored

A good portion of code is redundant, fix this.

Original issue reported on code.google.com by [email protected] on 8 Feb 2011 at 8:26

ZIPTool 2.1.0 configure.ac needs to be cleaned up

Problem:
configure.ac was copied from another project and was not fully cleaned prior to 
release.

This results in the configure script checking for several unnecessary things.


Todo:
1. remove libtoolize stuff from the autogen.sh
2. clean up configure.ac
3. regenerate the auto-files.

Original issue reported on code.google.com by [email protected] on 11 Feb 2011 at 2:47

ZIPTool 2.0.0 will Corrupt Archives with Data Descriptors

ZIPTool will not handle data descriptors that follow compressed data, In fact 
I'm pretty confident that it will corrupt the unpure archive.

From the APPNOTE

--- snip ---

  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.

--- snip ---

Original issue reported on code.google.com by [email protected] on 9 Feb 2011 at 2:19

ZIPTool 2.0.0 Source Code Needs to be Pushed into the Repository

What steps will reproduce the problem?
1. do an svn checkout of the project

Expected Results:
version 2.0.0 is checked out

Actual Results:
version 1.0.0 is checked out

Original issue reported on code.google.com by [email protected] on 8 Feb 2011 at 8:24

ziptool abnormal termination (mingw build)

Steps to reproduce:

1. Configure and build ziptool under MinGW (MSys environment):
    $ svn checkout http://ziptool.googlecode.com/svn/tags/release-2.1.2/ ziptool-read-only
    $ cd ziptool-read-only/
    $ ./configure
    $ make
    $ cd src

2. Try to use ziptool:
    $ ziptool vms.pk3 my_custom_vms.pk3
3. Program terminated with output message: "terminate called after throwing an 
instance of 'std::ios_base::failure' what():  basic_ios::clear".

ziptool svn revision: 29.
gcc version: 4.5.2 (mingw installer from 2011-08-02)
OS: WinXP x86

Error details. 
Exception caused by line 115 (revision of "ziptool.cc": 18). See also: line 266 
and 285. The main reason of crash is that using wrong pattern for negative 
(reverse) offsets for "seek" functions, like that:

// warning: unary minus operator applied to unsigned type,
// result still unsigned
archive.seekg( -(sizeof(local)), ios_base::cur );

You can verify this under debugger:

streamoff testOffset = -(sizeof(local));   // "-30" expected, but...
archive.seekg( -(sizeof(local)), ios_base::cur );

(gdb) p testOffset
$1 = 4294967250     (!!! too bad !!!)

There is nothing surprising in the fact that the "seekg" function throws 
exception.

Possible solution to fix the issue:

archive.seekg( -(static_cast<streamoff>(sizeof(local)) ), ios_base::cur );

Original issue reported on code.google.com by [email protected] on 11 Sep 2011 at 8:07

wrong crc

Hi, Am using cygwin on windows xp for runing ziptool rev 6 .
i tried to purify data-1.1.0.pk3 but wont work.
 even if ZipFile1.zip and ZipFile2.zip are the same files with same crc32
the output file allways have wrong crc (9E02178B) instead of (894BB96D) .
dont know if that is an issue ,but anyways i cant use your tool and cant
solve my problem by myself , thank you

Original issue reported on code.google.com by [email protected] on 5 Sep 2009 at 11:40

ZIPTool 2.0.0 Endianness Issues occur on BIG ENDIAN Architectures

The pkzip file format uses little endian byte storage for header values, this 
allowed me to be lazy when writing it but it will not work on a PPC box.

2 possible fixes

Use byte shift reads (via macros) to make the code endianness independent.

OR

preform byte swaps for 4 byte and 2 byte values where needed.


Either solution will do however i'm not concerned about fixing this anytime 
soon.

Original issue reported on code.google.com by [email protected] on 8 Feb 2011 at 8:31