File attributes incompatible with WinZip

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?

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?

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.

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.

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.

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?

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.