It appears that Real-time Zip, when creating a new zip archive, is writing a value of 0x0008 to the general purpose bit flag of the local file header to indicate the use of data descriptor records.  The zip specification states that bit 3 should be set to indicate this.  Another tool I've used to parse existing zip files looks for a value of 0x0004 in that field.

My question is, who is right?  I can see if you are counting bits using 0-based counting, then bit 3 turned "on" would be 0x0008.  But if you assume 1-based counting then bit 3 turned "on" would be 0x0004.

My initial thought is that Real-time Zip is in error and is actually flipping bit 4 by writing the value 0x0008.

-Steve 

We indeed use zero-based counting. So to set bit 3 is to use the value 0x8, which, in binary will be 1000.

If you look at the Zip specification, it also uses zero-based counting when talking about bitfields.