Help for updating one file within Zipped file

Apr 12, 2010 at 3:08 AM

Currenlty I am working on DWF file which can be treated as ZIP file. I need to update single *.content.xml file within DWF file.

Here is what I did:

1, Read DWF file as zip file, ( No problem in this step)

2, Find that  *.content.xml file in root directory, Then extract it to a temp folder and update that file

3, go back to DWF update *.content.xml file using  UpdateFile() , Put updated file in the root directory.

4, Call Save() to save DWF file. Here is the problem. After this SAVE() was called, the DWF could not be opened at all. Seems like this DWF file was damaged.

Also, I tried to use WinZip to do the same work manually and got no problem. Sucessfully update that *.content.xml file without DWF file damaged. Since I dont know about the details of WinZip. Here is what I did. Use WinZip to open DWF file --> All files inside DWF are listed in WinZip ---> Drag updated *.content.xml to WinZip window to update the old one ---> Close WinZip. That is it.

So, my question is if I can achieve the same result by using DotnetZip?

Any help is appreciated. Thanks,


Apr 12, 2010 at 2:33 PM
Edited Apr 12, 2010 at 2:36 PM

in theory what you describe should work.  I don't know the DWF format; there are lots of possibilities as to why a zip file may not be a valid DWF file.  Text encoding,  Encryption, ZIP64, and bit 3 formatting are just a few that I can think of.   If I were you I'd examine the inner structure of the zip file, before and after updating, with something like unzip -i .

Or, in a program, use the ZipFile.Info property .

Once you figure out the differences, then I might be able to help you to avoid those differences when you update the DWF with DotNetZip.

Apr 12, 2010 at 6:53 PM

Cheeso, Thank you for your reply.  Here is what I did:

1, Retreive ZipFile.Info from DWF

2, Read DWF as Zip, Save it directly without updating any file. And then retreive the ZipFile.Info once again.

3, Compare the Zipfile Info property and found "Relative Offset" value was modified.

                               Original DWF file         New DWF file

The first file:                  0XC                               0X0

The Second file:        0X59                              0X4D

third one:                      0X395                            0X389              this is the one to be updated

So, I have no idea if this value change does damage DWF file. If so, is there anyway to fix this value?

  ZipEntry: filename.content.xml
  Version Made By: 0x14
  Version Needed: 0x14
  Compression Method: Deflate
  Compressed: 0xD64
  Uncompressed: 0x813B
  Disk Number: 0
  Relative Offset: 0x395
  Bit Field: 0x0000
  Encrypted?: False
  Timeblob: 0x3C894B0D (4/9/2010 9:24:26 AM)
  CRC: 0x687087E3
  Is Text?: True
  Is Directory?: False
  Is Zip64?: False

Thank you for your help, Cheeso.

Apr 13, 2010 at 4:02 PM

The relative offset is the point in the file where the data for that particular file entry begins. 

The "first file" is interesting. It shows the relative offset is 0xC, which means the first entry does not start at position 0 in the zip file. This is legal and also uncommon.  What lies ahead of offset 0xC?  What is contained in those first 12 bytes?  DotNetZip does not know about that stuff, and if those 12 bytes contain a pointer to something else in the file, then it could easily get de-synchronized with the rest of the zip file, if you change the zip entries.

Is there only one entry in each DWF file?  I'm guessing not.  But you showed the zip info for only one entry.  ??

Also - what do you mean by your original statement "the updated DWF file could not be opened at all" ?    Does that mean, that it cannot be opened as a zip file?  I would think not.  You are able to get the zip info on the updated file.  So that must mean the resulting DWF file IS a valid zip file.  And therefore, by your statement, you must mean that it cannot be opened as a DWF file, by... what is DWF? I guess an autodesk file, right?

Reading a little on this, it seems DWF is a doc format that conforms to the Open Packaging Conventions, and so can be read with the System.IO.Packaging classes.   Any reason you're not doing that? 

Getting back to your problem, if unzip -i thinks the updated zip is a valid zip file, then you need to roll up your sleeves, understand the OPC, how the DWF format inter-relates, and why that valid zip is not a valid DWF.  How?  I don't know.  Maybe try  


Apr 14, 2010 at 4:20 PM


Thank you for such a detailed reply. Yes, as you said, DWF file is autodesk file.  Actually I dont know DWF at all.

I really dont know what the first 12 bytes is. Maybe it is created by autodesk.  and there are 19 entries in DWF.

Anyway, I used Winzip command in my code to work around it even though I dont like to do it in this way.

I will try your suggestion, use System.IO.Packaging classes.

Thanks again,