Obsolete documentation under ZipEntry unix style path separator

[hoborm]

Steps to reproduce

1. Create a ZipEntry ("somefolder\someentryname") with Windows style separator and add it to a zipfile
2. Try to find a zipentry with zipfile.FindEntry(@"somefolder\someentryname")
3. The FindEntry cannot find it.

Version 1.2.0:

In the documentation the ZipEntry constructor says:
/// The convention for names is 'unix' style paths with no device names and /// path elements separated by '/' characters. This is not enforced see <see cref="CleanName(string)">CleanName</see> /// on how to ensure names are valid if this is desired.

However it's enforced (line 214):
this.name = CleanName(name);

Version 0.86.0:

In the version 0.86.0 the ZipEntry documentation says the unix style separator is not enforced and indeed it is not enforced. See (line 254):
name = entry.name;

Commit of the change:
af0ee8d

Version of SharpZipLib

1.2.0 and 0.86.0

Obtained from

• Downloaded from GitHub (0.86.0)
• Package installed using NuGet (1.2.0)

It's a breaking change from 0.86.0 to 1.2.0 (It's present in 1.0.0 aswell). We, unfortunately, used the FindEntry with Windows "\" separator and worked, however, it broke upon upgrading to newer versions.

[Numpsy]

The change to call CleanName is potentially rolled by by #362

[hoborm]

You are right. Thank you for letting me know. This is a duplication of #341

[piksel]

Thanks for linking the commit. I'm still confused about why this change was made in the first place. It seems to just break use cases, but I presume it was solve a specific one?

[Numpsy]

The bug tracker link attached to the commit seems dead, but there is an archived version at https://web.archive.org/web/20100703011409/http://bugtracker.sharpdevelop.net/issue/ViewIssue.aspx?id=1676&PROJID=2 which mentions converting between forwards and backwards slashes.

Not sure what the current situation is with slashes in ZipOutputStream, but I think there have been other attempts to fix the delete issues in ZipFile?