nils måsén
nils måsén
This will probably be in the next release. I have been super busy and neglected this unfortunately. Hopefully I will get time this weekend to fix current issues.
@Numpsy I made suggestions that should make it compatible with non-seekable streams. It will not access Stream.Length if `multistream` is not enabled, and it defaults to enable it only if...
Who knows? I don't think anyone is working on it at the moment though.
Don't think anyone is working on implementing it currently. If you are up to it, a PR would be welcomed!
@yoer > Don't think anyone is working on implementing it currently. If you are up to it, a PR would be welcomed!
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...
It should be possible to fix this without allowing absolute paths. If we really want to add support for them, they should have to be explicitly be turned on since...
This could be fixed by simply calling `ZipFile.BeginUpdate();` and `ZipFile.CommitUpdate();` in `ZipFile.Create()` if the file didn't already exist (or if it's size is 0).
NPOI does not use the affected parts of SharpZipLib (tar archives) AFAIK (since it deals with zip files). In any case, we can't do anything about what version they are...
Yeah, this has to do with relative vs. absolute file paths. When an absolute path is specified, it's of course unexpected for it to be handled as a relative path....