sharpcompress Issue Tracker Rss Feed

Commented Unassigned: Protect against double-disposal in Streams [36]

EMonk — Tue, 21 May 2013 21:32:16 GMT

In certain situations it is possible to have the Dispose method of a stream called multiple times. When this happens in the various compression streams in SharpCompress it can cause exceptions when the stream's Dispose code tries to finalize the compression algorithm multiple times.

For instance, in PpmdStream.cs
```
protected override void Dispose(bool isDisposing)
{
if (isDisposing)
{
if (compress)
model.EncodeBlock(stream, new MemoryStream(), true);
}
base.Dispose(isDisposing);
}
```

If this is called twice, the model.EncodeBlock method will result in an exception deep in the model's code, with no easy link back to the source of the exception.

Either the compression stream classes or their models should check for the encoding process being finalized before trying to finalize it a second time. A _disposed_ flag in the stream class for instance, or a flag in the model that is set when the encoding is finalized, with appropriate error messages for attempts to continue to use a finalized model.
Comments: Thanks for the library :)

Commented Unassigned: Protect against double-disposal in Streams [36]

adamhathcock — Mon, 20 May 2013 08:15:04 GMT

Created Unassigned: Protect against double-disposal in Streams [36]

EMonk — Sun, 19 May 2013 03:54:09 GMT

Commented Unassigned: Open tar archive from stream [35]

pjakobczyk — Tue, 07 May 2013 16:33:46 GMT

When I try to open tar archive from stream using method ArchiveFactory.Open(Stream, Options), the archive is recognize as rar. In consequence, when I try to read archive entries I get InvalidFormatException (Invalid Rar Header).
Comments: Thanks a lot for a quick fix. BTW. SharpCompress is very smart and useful library.

Commented Unassigned: Open tar archive from stream [35]

adamhathcock — Tue, 07 May 2013 13:33:00 GMT

When I try to open tar archive from stream using method ArchiveFactory.Open(Stream, Options), the archive is recognize as rar. In consequence, when I try to read archive entries I get InvalidFormatException (Invalid Rar Header).
Comments: Fix for what you found: https://github.com/adamhathcock/sharpcompress/commit/483f2e564a49c5ac17a92f8ae97f00db3424a514

Commented Unassigned: Open tar archive from stream [35]

pjakobczyk — Tue, 07 May 2013 13:04:36 GMT

When I try to open tar archive from stream using method ArchiveFactory.Open(Stream, Options), the archive is recognize as rar. In consequence, when I try to read archive entries I get InvalidFormatException (Invalid Rar Header).
Comments: I took a look at the problem closer. The problem is not with tar header but with method ArchiveFactory.Open taking Stream argument. ArchiveFactory.Open method which take FileInfo works fine. It seems that there is no LookForHeader option in RarArchive.IsRarFile invocation and the archive stream is recognized as rar.

Commented Unassigned: Open tar archive from stream [35]

adamhathcock — Tue, 07 May 2013 12:24:46 GMT

Created Unassigned: Open tar archive from stream [35]

pjakobczyk — Tue, 07 May 2013 10:43:21 GMT

Closed Issue: Failed to decompress Lzma2 stream with only 1 byte of data [28]

adamhathcock — Sun, 28 Apr 2013 10:34:27 GMT

Closed Issue: Stops extracting rar archives after the first entry when reading from a network stream [29]

adamhathcock — Sun, 28 Apr 2013 10:33:57 GMT

I've tried to decompress an incoming rar file in a WCF service method: the stream is created on the client side by opening a rar file for reading. Then this stream is passed to a wcf service. The service opens stream using ReaderFactory.Open(). Unfortunately the decompression stopps after the first file is extracted from the archive. The reader.MoveToNextEntry() returns false though the stream was not completely read yet and there is still a file left in the compressed stream. The code to reproduce this behavior and the test archive is included in the attached file.

Thank you in advance!
Comments: Works with BufferedStream

Commented Issue: Failed to decompress Lzma2 stream with only 1 byte of data [28]

mattiasz — Mon, 08 Apr 2013 13:48:20 GMT

Commented Issue: Failed to decompress Lzma2 stream with only 1 byte of data [28]

adamhathcock — Mon, 08 Apr 2013 11:10:36 GMT

Steps to reproduce:
1. Compress a character 'X' using Lzma2 (make sure it outputs an uncompressible chunk)
2. Use LzmaStream decompress that 1 character
3. The code hangs-up in a loop because CopyStream returns 0 (extra check/assert here?)

Resolved by adding
outWindow.SetLimit(toProcess);
somewhere on line LzmaStream.cs:184

if (uncompressedChunk)
{
outWindow.SetLimit(toProcess); // BUG: added this line
inputPosition += outWindow.CopyStream(inputStream, toProcess);
}
else
{
outWindow.SetLimit(toProcess);
if (decoder.Code(dictionarySize, outWindow, rangeDecoder) && outputSize < 0)
availableBytes = outWindow.AvailableBytes;
}

test code:
```
[TestMethod]
public void TestLzma2Decompress1Byte()
{
byte[] properties = new byte[] { 0x01 };
byte[] compressedData = new byte[] { 0x01, 0x00, 0x00, 0x58, 0x00 };
MemoryStream lzma2Stream = new MemoryStream(compressedData);

SharpCompress.Compressor.LZMA.LzmaStream decompressor = new SharpCompress.Compressor.LZMA.LzmaStream(properties, lzma2Stream, 5, 1);
Assert.AreEqual('X', decompressor.ReadByte());
}
```
Comments: Added your fix here:https://sharpcompress.codeplex.com/SourceControl/changeset/fcca5e95eafd I'll do another release soon as I want to move the source to github Thanks!

Commented Issue: Failed to decompress Lzma2 stream with only 1 byte of data [28]

mattiasz — Mon, 08 Apr 2013 09:52:07 GMT

Commented Issue: Failed to decompress Lzma2 stream with only 1 byte of data [28]

mattiasz — Mon, 08 Apr 2013 09:49:07 GMT

Steps to reproduce:
1. Compress a character 'X' using Lzma2 (make sure it outputs an uncompressible chunk)
2. Use LzmaStream decompress that 1 character
3. The code hangs-up in a loop because CopyStream returns 0 (extra check/assert here?)

Resolved by adding
outWindow.SetLimit(toProcess);
somewhere on line LzmaStream.cs:184

if (uncompressedChunk)
{
outWindow.SetLimit(toProcess); // BUG: added this line
inputPosition += outWindow.CopyStream(inputStream, toProcess);
}
else
{
outWindow.SetLimit(toProcess);
if (decoder.Code(dictionarySize, outWindow, rangeDecoder) && outputSize < 0)
availableBytes = outWindow.AvailableBytes;
}

test code:
```
[TestMethod]
public void TestLzma2Decompress1Byte()
{
byte[] properties = new byte[] { 0x01 };
byte[] compressedData = new byte[] { 0x01, 0x00, 0x00, 0x58, 0x00 };
MemoryStream lzma2Stream = new MemoryStream(compressedData);

SharpCompress.Compressor.LZMA.LzmaStream decompressor = new SharpCompress.Compressor.LZMA.LzmaStream(properties, lzma2Stream, 5, 1);
Assert.AreEqual('X', decompressor.ReadByte());
}
```
Comments: I also had this problem when I was trying to decompress a 5 MB+ LZMA2 stream. Solved it by applying TuboZakacate's solution. I can confirm that this solution works on all 163 different streams that I have tried so far. Also extracted the proposed solution from the if statement to save one line of code: ``` outWindow.SetLimit(toProcess); if (uncompressedChunk) inputPosition += outWindow.CopyStream(inputStream, toProcess); else if (decoder.Code(dictionarySize, outWindow, rangeDecoder) && outputSize < 0) availableBytes = outWindow.AvailableBytes; } ``` It would be awesome if this solution got into the source code so I can use this wonderful library directly from NuGet.

Commented Issue: How can I make SharpCompress preserve file execution settings? [34]

adamhathcock — Tue, 02 Apr 2013 09:31:45 GMT

Hi,

Thanks for a great library. I'm using SharpCompress for creating and extracting tar.gz files. When doing so I can't seem to have the extract part preserve the exec flag on the extracted files. Is there an option I'm missing here?

This is the code I'm using to extract files:

public static void Decompress(string directory, string archiveFile) {
using (Stream gz = File.Open(archiveFile, FileMode.Open)) {
using (var gzArchive = ArchiveFactory.Open(gz)) {
var tarEntry = gzArchive.Entries.First();
using (var tar = new MemoryStream()) {
tarEntry.WriteTo(tar);
using (var tarArchive = ArchiveFactory.Open(tar)) {
foreach (var entry in tarArchive.Entries.Where(entry => !entry.IsDirectory)) {
entry.WriteToDirectory(
directory,
ExtractOptions.ExtractFullPath | ExtractOptions.Overwrite);
}
}
}
}
}
}

-Svein Arne
Comments: My Tar code doesn't write the file attributes out as they are in the Tar specification currently.

Created Issue: How can I make SharpCompress preserve file execution settings? [34]

ackenpacken — Mon, 01 Apr 2013 10:58:34 GMT

Commented Issue: WinRT support [3]

igorkulman — Tue, 19 Mar 2013 13:24:53 GMT

Have you made any progress on WinRT support? I forked your project and changed your "NotImplementedExceptions()" to return default(DateTimeOffset) instead, but still get an exception saying that it is not implemented. I am testing from a Metro Javascript project.

I probably need to add the projects to my JS solution (I had just been adding the compiled winmd file) and try to step into the C# code, although I'm not sure if you can step into C# from JS.

My next avenue is to strip out all references to System.IO as that seems to be a problem with compiling in Release mode (if stepping into the C# and finding the problem doesn't work). But I was wondering if you had done any more testing yourself? I have tested with ZIP and RAR files, and get the same problem.
Comments: Any plans for WinRT support? The built-in ZipArchive does not support reading password protected files.

Commented Issue: Recognize Anti-Items in 7zip archives [33]

mafutrct — Sun, 17 Mar 2013 20:36:09 GMT

Right now, there does not seem to be a way to recognize anti-items in 7zip files.

Please add a field to IArchiveEntry that indicates whether an item is an anti-item.
Comments: Thank you for the quick reply! Personally, I do not need them right now, but I think others would be interested. I think adding a bool IsAnti to ArchiveEntry would solve this in a flexible manner (in a backwards-compatible way, even).

Edited Issue: Endless loop in SeekableZipHeaderFactory on broken archives [31]

adamhathcock — Sun, 17 Mar 2013 18:03:36 GMT

When reading from a corrupt zip file, SeekableZipHeaderFactory, ReadSeekableHeader performs an endless do/while loop (applicable to 0.8.2):

```
do
{
if ((stream.Length + offset) - 4 < 0)
{
throw new ArchiveException("Failed to locate the Zip Header");
}
stream.Seek(offset - 4, SeekOrigin.End);
signature = reader.ReadUInt32();
offset--;
//i++;
//if (i > 1000) throw new ArchiveException("Archive damaged. Endless Loop in ReadSeekableHeader detected.");

} while (signature != DIRECTORY_END_HEADER_BYTES);
```

From what I observed, the usual number of iterations here is 19. But when the corrupted file is processed, it never ends. I did the ugly quick-fix, setting the max iterations to 1000 and then throwing an exception, otherwise the whole application hangs up forever. If it's possible to fix the problem in any other way, it would be much appreciated.

Since the zip file is too big for Codeplex. I uploaded it here: http://www.sendspace.com/file/d6vwj6

Commented Issue: Recognize Anti-Items in 7zip archives [33]

adamhathcock — Sun, 17 Mar 2013 18:02:09 GMT

Right now, there does not seem to be a way to recognize anti-items in 7zip files.

Please add a field to IArchiveEntry that indicates whether an item is an anti-item.
Comments: Would it be better to just hide the entries or do you want to have them?