File attributes incompatible with WinZip

Jun 23, 2009 at 10:42 AM

I have spotted another problem relating to WinZip compatibility.  This time it concerns the file attributes.  I notice that DotNetZip sets the upper byte of the version made by field to 10 which according to the standard is NTFS.  However, WinZip sees this as TOPS-20 and doesn't recognise the file attributes.

If you create a Zip file with WinZip itself it sets the upper byte of the version made by field to 0 which it recognises as "MS-DOS, OS/2, NT FAT".  Is there any chance you could change DotNetZip to use 0 instead of 10 so that the file attributes are compatible with WinZip?

Thanks.

Coordinator
Jun 23, 2009 at 11:11 AM
Edited Jun 23, 2009 at 11:29 AM

Wow, you are really getting into the guts of this thing.  I appreciate the extra effort.

Are you saying there's a bug in WinZip and you want DotNetZip to change to accomodate it?

I'm not sure that is a good idea.  The problem is that the File Attributes are OS specific.  Setting the "version made by" field to MS-DOS means the file attributes have a different meaning, according to my understanding of the spec. 

So if WinZip is breaking the spec, maybe you should be asking WinZip to change, rather than DotNetZip.  Maybe I am much more responsive that the WinZip guys, but that doesn't mean that DotNetZip should change.  Maybe DotNetZip is much smaller than WinZip, but again that is still not a good justification to introduce a bug.  What about all the other archivers out there who try to be compliant? 

Is it possible there is some misunderstanding?  What does WinZip insert for the 2-byte Version Made By field? 

Jun 23, 2009 at 12:21 PM

I'm not sure if it's a bug in WinZip - maybe a different interpretation of the standard.  The point is that files created with DotNetZip are not fully compatible with WinZip which is probably one of the most popular Zip utilties out there.

WinZip puts 0x0014 for the Version Made By field.

Coordinator
Jun 23, 2009 at 1:29 PM

I understand what you're saying. 

A while ago, DotNetZip always used 0 for the upper byte of the "version made by" field, just like WinZip. Then someone asked for file attributes to be encoded into the zip, and also properly applied upon extraction. (workitem 7071)  The meaning of the file attributes field depends on the value of the "Version made by", and specifically on the encoded OS version.  So I modified DotNetZip to store and set the NTFS file attributes, and also encode NTFS in the "version made by" field.

At least I thought they were NTFS attributes. If the attributes I get back from File.GetAttributes() are not NTFS attributes but are FAT attributes, then the upper byte of Version Made By should be zero, as you suggest, and as WinZip has it.  This isn't quite true - the value returned from File.GetAttributes includes attributes that apply to FAT, and also may include some attributes that are supported only on NTFS.   But I can special case those. 

So I think we can do what you suggest - encode 0, and keep DotNetZip compatible.

In any case, 10 in the OS version is clearly NTFS, not TOPS-20.  I don't see a way around that.  But I guess it's a moot point if DotNetZip always stores zero.

Coordinator
Jun 23, 2009 at 1:32 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Jun 23, 2009 at 1:47 PM

Yes, I agree - it looks as though WinZip only stores FAT attributes (archive, directory, hidden, system, read-only) and hence sets the Version Made By to zero.  DotNetZip, I presume, is storing all attributes including extra NTFS ones so setting the Version Made By to 10 is correct according to the standard.

So, both WinZip and DotNetZip are doing the right thing but the problem is that they are incompatible with each other.  Neither can read the attributes in a Zip file created by the other.

As far as I am concerned I only care about the FAT attributes being stored in the Zip file and I'd really like WinZip and DotNetZip to be compatible with each other.

Coordinator
Jun 23, 2009 at 3:48 PM
Edited Jun 23, 2009 at 3:56 PM

I agree, compatibility is very important.

EDIT:

How do you see "Tops-20" for the Version Made By?

I just installed WinZip 12 trial version, and I cannot find the "Version made by" nor any indication that WinZip does not understand the file attributes stored by DotNetZip. Can you help me out here?  How did you determine that WinZip cannot handle what DotNetZip produces?

Jun 23, 2009 at 6:54 PM

If you use the WinZip command line and run:

wzzip -vt <filename>

it displays a listing of all the files in the Zip file.  In the "Created by" field it says "4.5 under TOPS-20".  The Attributes field is blank even if the original file had attributes such as read-only or hidden set.  In the WinZip application the Attributes column is also always blank - you may need to enable the Attributes column because I don't think it appears by default.

Coordinator
Jun 23, 2009 at 8:05 PM

Got it.

OK I downloaded the Winzip command line tool and got the expected results, both before and after the fix.
The attributes seem to be picked up correctly.

now to write some test code...