[
  {
    "Id": "429860",
    "ThreadId": "208998",
    "Html": "<p>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.</p>\r\n<p>Here is what I did:</p>\r\n<p>1, Read DWF file as zip file, ( No problem in this step)</p>\r\n<p>2, Find that&nbsp; *.content.xml file in root directory, Then extract it to a temp folder and update that file</p>\r\n<p>3, go back to DWF update *.content.xml file&nbsp;using&nbsp;&nbsp;UpdateFile() , Put updated file in the root directory.</p>\r\n<p>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.</p>\r\n<p>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.&nbsp;Since I dont know about the details of WinZip.&nbsp;Here is what I did.&nbsp;Use WinZip to open DWF file --&gt; All files inside DWF are listed in WinZip&nbsp;---&gt; Drag updated *.content.xml to WinZip window to update the old one ---&gt; Close WinZip. That is it.</p>\r\n<p>So, my question is if I can achieve the same result by using DotnetZip?</p>\r\n<p>Any help is appreciated. Thanks,</p>\r\n<p>Harbin</p>",
    "PostedDate": "2010-04-11T20:08:33.24-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "430027",
    "ThreadId": "208998",
    "Html": "<p>in theory what you describe should work.&nbsp; 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.&nbsp; Text encoding,&nbsp; Encryption, ZIP64, and bit 3 formatting are just a few that I can think of. &nbsp; If I were you I'd examine the inner structure of the zip file, before and after&nbsp;updating,&nbsp;with something like <strong>unzip -i </strong>.</p>\r\n<p>Or, in a program, use the ZipFile.Info property .</p>\r\n<p>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.</p>",
    "PostedDate": "2010-04-12T07:33:36.93-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "430150",
    "ThreadId": "208998",
    "Html": "<p>Cheeso, Thank you for your reply.&nbsp; Here is what I did:</p>\r\n<p>1, Retreive ZipFile.Info from DWF</p>\r\n<p>2, Read DWF as Zip, Save it directly without updating any file. And then retreive the ZipFile.Info once again.</p>\r\n<p>3, Compare the Zipfile Info property and found &quot;Relative Offset&quot; value was modified.</p>\r\n<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Original DWF file&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;New DWF file</p>\r\n<p>The first file:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0XC&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0X0</p>\r\n<p>The Second file:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0X59&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0X4D</p>\r\n<p>third one:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;0X395&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0X389&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; this is the one to be updated</p>\r\n<p><span style=\"color:#800000\">So, I have no idea if this value change does damage DWF file. If so, is there anyway to fix this value?</span></p>\r\n<p>&nbsp;&nbsp;ZipEntry: filename.content.xml<br>&nbsp; Version Made By: 0x14<br>&nbsp; Version Needed: 0x14<br>&nbsp; Compression Method: Deflate<br>&nbsp; Compressed: 0xD64<br>&nbsp; Uncompressed: 0x813B<br>&nbsp; Disk Number: 0<br>&nbsp;<span style=\"color:#800000\"> <strong>Relative Offset: 0x395</strong><br></span>&nbsp; Bit Field: 0x0000<br>&nbsp; Encrypted?: False<br>&nbsp; Timeblob: 0x3C894B0D (4/9/2010 9:24:26 AM)<br>&nbsp; CRC: 0x687087E3<br>&nbsp; Is Text?: True<br>&nbsp; Is Directory?: False<br>&nbsp; Is Zip64?: False</p>\r\n<p>Thank you for your help, Cheeso.</p>",
    "PostedDate": "2010-04-12T11:53:55.047-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "430524",
    "ThreadId": "208998",
    "Html": "<div style=\"width:800px\">\r\n<p>The relative offset is the point in the file where the data for that particular file entry begins.&nbsp;</p>\r\n<p>The &quot;first file&quot; 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.&nbsp; What lies ahead of offset 0xC?&nbsp; What is contained in those first 12 bytes?&nbsp; 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.</p>\r\n<p>Is there only one entry in each DWF&nbsp;file?&nbsp; I'm guessing not.&nbsp; But you showed the zip info for only one entry.&nbsp; ??</p>\r\n<p>Also - what do you mean by your original statement &quot;the updated DWF file could not be opened at all&quot; ?&nbsp;&nbsp;&nbsp; Does that mean, that it cannot be opened as <em>a zip file</em>?&nbsp; I would think not.&nbsp; You are able to get the zip info on the updated file.&nbsp; So that must mean the resulting DWF file IS a valid zip file.&nbsp; And therefore, by your statement,&nbsp;you must mean that it cannot be opened as a DWF file, by... what is DWF? I guess an autodesk file, right?</p>\r\n<p>Reading a little on this, it seems DWF is a doc format that conforms to the <a href=\"http://msdn.microsoft.com/msdnmag/issues/07/08/OPC/default.aspxhttp://msdn.microsoft.com/msdnmag/issues/07/08/OPC/default.aspx\">Open Packaging Conventions</a>, and so can be read with the System.IO.Packaging classes.&nbsp;&nbsp; Any reason you're not doing that?&nbsp;</p>\r\n<p>Getting back to your problem, if <strong>unzip -i</strong> 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,&nbsp;and why that valid zip is not a valid DWF.&nbsp; How?&nbsp; I don't know.&nbsp; Maybe&nbsp;try <a href=\"http://diffopc.arstdesign.com/\">http://diffopc.arstdesign.com/</a>&nbsp;&nbsp;</p>\r\n<p>&nbsp;</p>\r\n</div>",
    "PostedDate": "2010-04-13T09:02:09.76-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "431005",
    "ThreadId": "208998",
    "Html": "<p>Cheeso,</p>\r\n<p>Thank you for such a detailed reply. Yes, as you said, DWF file is autodesk file.&nbsp; Actually I dont know DWF at all.</p>\r\n<p>I really dont know what&nbsp;the first 12 bytes is. Maybe it is created by autodesk.&nbsp; and there are 19 entries in DWF.</p>\r\n<p>Anyway, I used Winzip command in my code to work around it even though I dont like to do it in this way.</p>\r\n<p>I will try your suggestion, use System.IO.Packaging classes.</p>\r\n<p>Thanks again,</p>\r\n<p>Harbin</p>",
    "PostedDate": "2010-04-14T09:20:42.893-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  }
]