[
  {
    "Id": "427197",
    "ThreadId": "208287",
    "Html": "<p>Hi there</p>\r\n<p>Given ZIP files are inherently hiearchical, I was wondering how to easily browse the contents of a ZIP file (e.g. getting a directory's child directories/files, or getting an entry's parent. From a first glance, it appears to me that no such functionality is present, but I might overlooked it. In case DNZ doesn't support browsing, are there any things to consider given the following strategy:</p>\r\n<ul>\r\n<li>Iterate througn all entries</li>\r\n<li>Create the hiearchy in an independent data structury (probably a tree of some sorts) based on path information</li>\r\n<li>Recreate the tree whenever the ZIP file's contents have been changed</li>\r\n</ul>\r\n<p>Cheers</p>\r\n<p>Philipp</p>",
    "PostedDate": "2010-04-04T05:17:23.723-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "427595",
    "ThreadId": "208287",
    "Html": "<p>Hi Philipp,</p>\r\n<p>It's not the case that zip files are inherently hierarchical.&nbsp; Filesystems are, but zip files definitely are not! &nbsp;</p>\r\n<p>Reflecting that, there is no support within the ZipFile type in DotNetZip for navigating that hierarchy.&nbsp;&nbsp; On the other hand, you could implement this fairly easily with&nbsp;the FileSelector class, or with a LINQ query on the FileName property of the&nbsp;ZipEntry instances contained within a ZipFile.</p>\r\n<p>As for&nbsp;creating a hierarchy and re-creating that tree when the zip file's contents have been changed&nbsp;- I don't know exactly what you mean.&nbsp; There is a way to produce a tree.&nbsp; One of the example applications in the source distribution is a C#/WinForms app that displays the contents of the zip file in a&nbsp;TreeView.&nbsp;&nbsp;<a href=\"http://dotnetzip.codeplex.com/SourceControl/changeset/view/57130#1041966\">http://dotnetzip.codeplex.com/SourceControl/changeset/view/57130#1041966</a>&nbsp;</p>\r\n<p>As for updating the tree when the content of the zipfile changes - I suppose you'd have to just re-create the tree. As I described above, there's no state retained in the ZipFile class that models the hierarchy you described.&nbsp; You'd have to maintain that yourself.&nbsp; There is also no &quot;ZipFile.Changed&quot;&nbsp; event, to notify you that a ZipFile has changed.</p>\r\n<p>I hope this helps...</p>\r\n<p>&nbsp;</p>\r\n<p>&nbsp;</p>",
    "PostedDate": "2010-04-05T13:44:20.1-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "427603",
    "ThreadId": "208287",
    "Html": "<p>Dino,</p>\r\n<p>I ended up building a simple repository of linked nodes (every node has one possible parent, and a child node collection) which I created based on the entries' file paths, pretty similar to your sample. As my provider manages write access to the ZIP file, it just invoked a Refresh method on the repository as soon as something is being changed.</p>\r\n<p>However, I haven't investigated that yet: Lets assume you have a huge ZIP file (e.g. several GB) which just contains a few directories and big files - how big is the cost of getting the entries off a ZipFile instance in terms of file I/O?</p>\r\n<p>Thanks for your advice</p>\r\n<p>Philipp</p>",
    "PostedDate": "2010-04-05T14:05:07.94-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "427822",
    "ThreadId": "208287",
    "Html": "<p>The zip directory is normally stored at the end of the zip file.&nbsp; For a large file, let's say 1gb,&nbsp;DotNetZip will seek to &quot;64 bytes before the end of the file,&quot; and look for the directory marker.&nbsp; Then seek to the directory, which usually immediately precedes that market.&nbsp; Then read the directory.&nbsp; There's one record in the directory for each zip entry in the file.&nbsp; Typically each record in the directory is between 40 and 70 bytes depending on the filename length and other things.&nbsp; If there are 8 files, then figure about 400 bytes of I/O to read the directory and get the ZipEntries.&nbsp; It's pretty fast if your media supports fast seeking.</p>\r\n<p>But try it and you'll see.</p>\r\n<p>&nbsp;</p>",
    "PostedDate": "2010-04-06T05:34:00.32-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "428177",
    "ThreadId": "208287",
    "Html": "<p>I'm more or less thinking about scenarios that may involve streaming ZIP files from a remote location. But given that a non-seekeable stream needs to be fully read in that case, I guess I need to expose the meta data differently.</p>\r\n<p>Thanks for the insight Dino :)</p>",
    "PostedDate": "2010-04-07T00:21:52.947-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "429247",
    "ThreadId": "208287",
    "Html": "<p>You can design streams that seek over Http and FTP.&nbsp;&nbsp; See, for example</p>\r\n<p><a href=\"http://cheeso.members.winisp.net/srcview.aspx?dir=streams\">http://cheeso.members.winisp.net/srcview.aspx?dir=streams</a></p>\r\n<p>&nbsp;</p>",
    "PostedDate": "2010-04-09T06:10:18.087-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  },
  {
    "Id": "429491",
    "ThreadId": "208287",
    "Html": "<p>Nice one, Dino. Didn't know about the Range option :)</p>",
    "PostedDate": "2010-04-10T02:11:44.767-07:00",
    "UserRole": null,
    "MarkedAsAnswerDate": null
  }
]