Home Forums .NET libraries Xceed Zip & Real-Time Zip for .NET Data descriptor record and the "3rd bit" of the general purpose bit flag

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • User (Old forums)
    Member
    Post count: 23064
    #20087 |

    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 

    Imported from legacy forums. Posted by Steve (had 3179 views)

    User (Old forums)
    Member
    Post count: 23064

    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.

    Imported from legacy forums. Posted by André (had 396 views)

    User (Old forums)
    Member
    Post count: 23064

    Great, thanks for the clarification!

    Imported from legacy forums. Posted by Steve (had 3040 views)

    User (Old forums)
    Member
    Post count: 23064

    What are the extra bit occurs when 3rd bit is not set .

     Thanks in advance.

     Regards

    Kanishk 

    Imported from legacy forums. Posted by Kanishk (had 958 views)

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.