Bad date/time format in the zip file

Dec 19, 2008 at 4:56 PM
I have compressed a lot of files using an older version of DotNet Zip library. Now I have updated at version 1.6 and when i try to unzip some files created using the older version, sometime I have an error: not a valid zip file. If  I open these files using winzip or unzip these folders in Window XP I have no problem... they seem to be valid.
I have downloaded the source code and I have noticed that the problem is in the static method PackedToDateTime of the internal class SharedUtilities, namespace Ionic.Utils.Zip.
For these not valid zip files, the second value calculated by this function is 60 so when the function try to create a new datetime value ( new System.DateTime(year, month, day, hour, minute, second, 0))  I have a System.ArgumentOutOfRangeException.
Probably, in the older version, this is ignored and in this case then function retun System.DateTime.Now.

        internal
         static DateTime PackedToDateTime(Int32 packedDateTime)
        {
            Int16 packedTime = (Int16)(packedDateTime & 0x0000ffff);
            Int16 packedDate = (Int16)((packedDateTime & 0xffff0000) >> 16);
            int year = 1980 + ((packedDate & 0xFE00) >> 9);
            int month = (packedDate & 0x01E0) >> 5;
            int day = packedDate & 0x001F;
            int hour = (packedTime & 0xF800) >> 11;
            int minute = (packedTime & 0x07E0) >> 5;
            //int second = packedTime & 0x001F;
            int second = (packedTime & 0x001F) * 2;
            DateTime d = System.DateTime.Now;
            try { d = new System.DateTime(year, month, day, hour, minute, second, 0); }
            catch (System.ArgumentOutOfRangeException ex1)
            {
                throw new ZipException("Bad date/time format in the zip file.", ex1);
                //Console.WriteLine("exception formatting the date: {0}\n\n", ex1.ToString());
                //Console.Write("\nInvalid date/time?:\nyear: {0} ", year);
                //Console.Write("month: {0} ", month);
                //Console.WriteLine("day: {0} ", day);
                //Console.WriteLine("HH:MM:SS= {0}:{1}:{2}", hour, minute, second);
            }
            return d;
        }

Why is the header date so important to throw new ZipException?
Coordinator
Dec 19, 2008 at 5:19 PM
Edited Dec 19, 2008 at 6:19 PM
yes -
in v1.6, I added logic to set the timestamp on files as they are being unpacked.
this means that older zip files with potentially out-of-range values for the timestamp will cause the new library to choke.
you can add this to the PackedToDateTime method:
// validation and error checking.
// this is not foolproof but will catch most errors.
if (second >= 60) {minute++; second=0;}
if (minute >= 60) {hour++; minute=0;}
if (hour >= 24) { day++; hour = 0; }

DateTime d = System.DateTime.Now;
try { d = new System.DateTime(year, month, day, hour, minute, second, 0); }

or wait just a bit and I will back-port this fix to v1.6.
Dec 19, 2008 at 5:32 PM
thank you for reply and sorry for my bad english
I hope you fix it relatively soon.

Bye.

Coordinator
Dec 19, 2008 at 6:20 PM
Ok, the validation of date/time is now available in the v1.6.3.15 release. 
Jan 27, 2009 at 3:57 PM
similar problem with v1.6.3.18 of the dll.
zip file works in winzip, and unzip that comes with unixutils (http://sourceforge.net/projects/unxutils)

ReadHeader can't seem to understand the block.
            ze._VersionNeeded = 20
            ze._BitField = 2
            ze._CompressionMethod = 8
            ze._TimeBlob = -1

here are the block bytes.
- block {Dimensions:[26]} byte[]
[0] 20 byte
[1] 0 byte
[2] 2 byte
[3] 0 byte
[4] 8 byte
[5] 0 byte
[6] 255 byte
[7] 255 byte
[8] 255 byte
[9] 255 byte
[10] 148 byte
[11] 98 byte
[12] 208 byte
[13] 121 byte
[14] 144 byte
[15] 23 byte
[16] 0 byte
[17] 0 byte
[18] 164 byte
[19] 86 byte
[20] 0 byte
[21] 0 byte
[22] 10 byte
[23] 0 byte
[24] 0 byte
[25] 0 byte


the timestamp on the file is 1/13/2009 11:18am
any thoughts?

thx.
s.

Coordinator
Feb 2, 2009 at 6:23 PM
I don't remember ever seeing a specification that said a timestamp value of 0xffffffff was valid. 
Are you saying you have such a zip archive?
how did you produce it?  With what tool? 

When you extract the file with winzip or unixutils, does it get the timestamp you mentioned (1/13/2009, etc) ?

It shouldn't be difficult to insert some logic to handle the case where the timestamp is 0xFFFFFFFF.  But it would go into the v1.7 library, as v1.6 is already final.

If this is what you want, please file a workitem and upload the zip archive.
Coordinator
Feb 12, 2009 at 4:45 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Oct 29, 2009 at 7:29 PM

I usually use for work with zip files different tools.But once some important zip archives were damaged.And no one of these tools couldn't help me.And a friend recommended to me-corrupt zip files recovery software.Software solved my problem easy and for free.