FastZip.CreateZip crashes when used with certain buggy Directory enumeration on .NET 5

[lscorcia]

Not really a bug, more like a feature suggestion.

Steps to reproduce

1. In .net 5, directory enumeration has bugs with WebDav (.Net Core Directory.GetFiles() operates webDav path dotnet/runtime#46723 (comment)), not fixed in .net 6 and with no other immediate official solution in sight;
2. This causes crashes when calling FastZip.CreateZip as the GetDirectories/GetFiles return invalid data;
3. A workaround is available - use something like this on the GetDirectories-returned data:

public static string[] FixupNet5Enumeration(string[] items)
{
    return items
        .Select(t => t.TrimEnd('\0'))
        .Where(t => {
            var itemName = Path.GetFileName(t);
            return itemName != "." && itemName != "..";
        })
        .ToArray();
}

4. SharpZipLib nicely wraps the Directory.GetDirectories call into the FileSystemScanner class. However it is not possible to supply custom FileSystemScanners to FastZip.CreateZip. It would be helpful in this case as I could just copy that class and insert the required fixup calls. It would be necessary to create an interface around FileSystemScanner and to change to public the method

SharpZipLib/src/ICSharpCode.SharpZipLib/Zip/FastZip.cs

Line 477 in 612969e

private void CreateZip(Stream outputStream, string sourceDirectory, bool recurse, FileSystemScanner scanner, bool leaveOpen)

What do you think?

Expected behavior

FastZip.CreateZip should offer an override to specify custom FileSystemScanners.

Actual behavior

FastZip.CreateZip throws exception as the paths returned by Directory.GetDirectories are not valid paths.

Version of SharpZipLib

1.3.3

Obtained from (only keep the relevant lines)

• Package installed using NuGet

[piksel]

In general it seems like a good idea to make it possible to extend SharpZipLib as much as possible for the consumers own purposes, so making the FileSystemScanner customizable seems like a good idea.

The only concern I have is encouraging the use of FastZip in the first place. The reason for that, is that the decisions about what is acceptable behaviour is done inside the library, with no information of what the actual use case is. This doesn't apply as much to CreateZip as it does to extracting though...