Hi,
it seems like that all the time properties of a zipped file return current time (CreationTime, LastAccessTime and LastWriteTime). Are the time properties stored somewhere in the zip, so that they could be used instead of the DateTime.Now?
Thank you

Hello dear @phillipp and thanks for this great project.
Trying the WPF sample, after extracting a file, an exception is thrown:
System.InvalidOperationException was unhandled by user code HResult=-2146233079 Message=SevenZipExtractor instance must not be disposed while making an asynchronous method call. Source=SevenZipSharp StackTrace: at SevenZip.SevenZipExtractor.Dispose() in c:\Users\Sepehr\Desktop\SevenZipSharp-master\SevenZip\SevenZipExtractor.cs:line 807 at SevenZipTestWPF.MainWindow.extr_ExtractionFinished(Object sender, EventArgs e) in c:\Users\Sepehr\Desktop\SevenZipSharp-master\SevenZipTestWPF\MainWindow.xaml.cs:line 78 at SevenZip.SevenZipBase.<OnEvent>b__0[T](EventHandler1 h, T ee) in c:\Users\Sepehr\Desktop\SevenZipSharp-master\SevenZip\Common.cs:line 141

SevenZipMono project does not contains COM.cs, InterfaceWrapper.cs and MonoSpec.cs. I think these files are not checked-in.

I ran into an issue uncompressing .gz and .bz2 files when using SevenZipSharpLib with a 7z.dll of version 16.04 or greater. These files would uncompress just fine using 7z.dll version 9.20.

After some time debugging the issue I found that the ArchiveExtractCallback.SetTotal() function is not being called when using the newer 7z.dll.

This results in _bytesCount being 0 when ArchiveExtractCallback.IntEventArgsHandler() is called. This results in a divide by zero error which the user sees as "The execution has failed due to the bug in the SevenZipSharp.".

I was able to work around this issue with the following code change in ArchiveExtractCallback.IntEventArgsHandler():

		FROM:
        var pold = (int)((_bytesWrittenOld * 100) / _bytesCount);
        _bytesWritten += e.Value;
        var pnow = (int)((_bytesWritten * 100) / _bytesCount);

		TO:

        var pold = (int)((_bytesWrittenOld * 100) / Math.Max(_bytesCount, 1));
        _bytesWritten += e.Value;
        var pnow = (int)((_bytesWritten * 100) / Math.Max(_bytesCount, 1));

This only fixes the divide by zero error, the real fix would require properly getting the uncompressed file size prior to the extraction.

I'm running SevenZipCompressor#CompressStreamDictionary(...) and noticed this has non-linear performance degradation as I add more files to the dictionary.

I ran a profiler while compressing 1 million 100KB files and it looks like the vast majority of the time is spent in ArchiveUpdateCallback#SetOperationResult(...).

Further digging showed this time is spent doing GC which appears to be manually invoked after every single file is compressed.

Can we stop calling or greatly reduce calls to GC.Collect() in SetOperationResult(...)?

Hi

Just wondering is it possible (to use SevenZipSharp) to only read the files in the source zip as bytes into memories, instead of having to extract the files to a directory