{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "Rejected",
    "ClosedDate": "2009-05-08T09:17:59.253-07:00",
    "CommentCount": 0,
    "Custom": null,
    "Description": "It would be helpful if constructors for classes such as Ionic.Zip.ZipFile accepted an IO.FileInfo. I don't think I'm alone in perfering to use FileInfo's instead of raw strings in my application.",
    "LastUpdatedDate": "2013-05-16T05:32:26.667-07:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2009-04-22T13:16:09-07:00",
    "Status": {
      "Name": "Closed",
      "Id": 4
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "Support for FileInfo",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 1,
    "Id": 7676
  },
  "FileAttachments": [],
  "Comments": [
    {
      "Message": "I'd like to understand more. what would you do with a FileInfo when constructing a ZipFile. ??",
      "PostedDate": "2009-04-28T10:23:55.607-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2009-04-28T10:24:13.857-07:00",
      "Id": -2147483648
    },
    {
      "Message": "Um... create a ZipFile object?\r\n\r\nI'm not asking for anything special, just the ability to pass in a FileInfo instead of a raw string, either way you still get a path to the file. I would like this because, like many people, I prefer to work with FileInfo objects rather than war strings containing paths. Since a FileInfo always contains within it the full path, there is never any doubt as to which file it is referring to.",
      "PostedDate": "2009-04-28T16:20:12.387-07:00",
      "Id": -2147483648
    },
    {
      "Message": "I think I see what you are asking for but I am not seeing the cost/benefit that would justify such a change.  \r\n\r\nLet me explain.\r\n\r\nYou may be aware that there are 6 ctor's for the ZipFile class. Four of them take strings which represent paths.  If I were to add support for FileInfo to the ctor's that would mean 4 new ctor's, for a total of 10 ctors. That seems like a bit much.  My current inclination is that I already have too many ctors.  Last time around I think I removed a bunch of them that accepted Streams.  (they were redundant anyway, with ZipFile.Read() methods.) \r\n\r\nIf I were to include FileInfo support, I would also want to support FileInfo in ZipFile.Read().   There are currently 8 overloads of ZipFile.Read() that accept pathnames, out of a total of 19 overloads of that static method.  I would need 8 additional overloads to support FileInfo, in order to be consistent, providing a total of 27.  Wow.  I think 19 is way too many.   \r\n\r\nBeyond the ctor and ZipFile.Read() methods, it seems logical and consistent that if DotNetZip were to accept FileInfo on the ctor's for ZipFile, it should also accept FileInfo types for adding files, or directories. The static IsZipFile() methods, the RemoveEntry() method, and so on. \r\n\r\nAll up this is looking like a pretty significant expansion of the DotNetZip interface, without a load of additional function.  I am hesitant to agree to this change, because of the high impact.   \r\n\r\nIf you find it handy to use FileInfo types, can you not either just pass in the FileInfo.Name, or create an extension method (assuming C# 3.0 compiler) to ZipFile class that does what you want?  \r\n",
      "PostedDate": "2009-04-29T12:39:58.32-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2009-05-08T09:17:59.253-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-02-21T18:44:23.74-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-05-16T05:32:26.667-07:00",
      "Id": -2147483648
    }
  ]
}