{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "fixed in changeset 22204.  This fix is in the v1.6 prelim release, currently available.  It will be in the v1.6 final release as well.",
    "ClosedDate": "2008-08-15T18:51:08.053-07:00",
    "CommentCount": 0,
    "Custom": null,
    "Description": "Hello!\nZipFile string indexer searches for ZipEntry comparing file names with == operator, which makes case sensetive comparison. But as we are dealing with file names, there has to be case insensetive comparison. This case raises unexpected NullReferenceException when we specify file name with different casing. I think string.Compare method with StringComparison.CurrentCultureIgnoreCase parameter will be more appropriate.\nIs the bug already solved? I'm using library version 1.5.\n \nRegards.",
    "LastUpdatedDate": "2013-05-16T05:32:40.913-07:00",
    "PlannedForRelease": "1.6 DotNetZip Library",
    "ReleaseVisibleToPublic": true,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2008-08-09T09:45:52.623-07:00",
    "Status": {
      "Name": "Closed",
      "Id": 4
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "case sensitive file names comparison",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 1,
    "Id": 5740
  },
  "FileAttachments": [],
  "Comments": [
    {
      "Message": "This is not good idea because .Net Zip library is potentially cross-platform!\r\n\r\nOn suse linux environments you can meet such perversion as Zip.cs and zip,cs in one dir!\r\nand when you comparing without case sensitive you'll have a potentioal bugs with porting your application on SUSE(it will be closely linked with Windows)",
      "PostedDate": "2008-08-11T09:16:08.487-07:00",
      "Id": -2147483648
    },
    {
      "Message": "As the library is written on .NET Framework, it is already closely linked to Windows. It's the cruel fact. Mono etc is not counted, library doesn't support it yet, as far as I know.\r\nI'm not going port my application on linux and now I'm having bugs because of case sensetivity in Windows. What am I supposed to do??",
      "PostedDate": "2008-08-11T13:11:39.2-07:00",
      "Id": -2147483648
    },
    {
      "Message": "This is a good change request, it makes sense for developers who work on Windows.  It is easy to conditional-compile it with WINDOWS or some other windows-only constant.  \r\n\r\nThat would allow for some future commitment to build the zip library on Mono/Suse, etc.  (But I  haven't committed to that). \r\n",
      "PostedDate": "2008-08-12T13:59:00.013-07:00",
      "Id": -2147483648
    },
    {
      "Message": "OK, so what I did was include a new public property on the ZipFile class called CaseSensitiveRetrieval, which is by default false.  If you set this property to true, then you get the case-sensitive behavior (which is what this workitem complained about).  By default though, the ZipFile reverts to case-insensitive retrieval of entries by the string indexer.  I am not using a conditional compile. Ideally the conditional compile would preset the default, depending on whether it was running on Win32 or not. But I will leave that for another day.  There are plenty of other gaps in the mono/non-Win32 support in this library. \r\n\r\n\r\n",
      "PostedDate": "2008-08-12T14:28:32.22-07:00",
      "Id": -2147483648
    },
    {
      "Message": "Thanks a lot!!!\r\nVery nice solution. When are you going to release new version?",
      "PostedDate": "2008-08-13T14:25:50.38-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2008-08-15T18:48:29.57-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2008-08-15T18:49:27.663-07:00",
      "Id": -2147483648
    },
    {
      "Message": "This is fixed in the v1.6 preview / interim release, available right now. (Check the releases tab).  \r\nIt will be in the v1.6 final release, which I expect to deliver before the end of August. \r\n",
      "PostedDate": "2008-08-15T18:50:06.29-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2008-08-15T18:51:08.053-07:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-02-21T18:44:43.223-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-05-16T05:32:40.913-07:00",
      "Id": -2147483648
    }
  ]
}