Timeout does not work for corrupt tar file

[svenclaesson]

Hi Gabe,

Ran into an issue with SharpCompress and an infinite loop adamhathcock/sharpcompress#736

Testing with this file (lib in python)
zoneinfo-2010g.zip

I would expect the timeout in RecursiveExtractor to catch this but no luck.
Assert.ThrowsException failed. Threw exception AssertFailedException, but exception TimeoutException was expected.

When used normally, it hangs forever.

[svenclaesson]

I can also mention that the built in System.Formats.Tar in .NET 7 handles this better by throwing
System.IO.InvalidDataException: The value of the size field for the current entry of type 'HardLink' is greater than the expected length.

[gfs]

Thanks for the Report and sample file Sven. That does seem like a case that the recursive extractor timeout should handle so I'll give that a look.

I have done a bit of preliminary testing with System.Formats.Tar as well, it should be simple to slot it in as an alternative.

[gfs]

Two Quick Follow Ups:

1. I did a bit of digging on this and recalled why I didn't complete the System.Format.Tar extractor previously. RecursiveExtractor targets .netstandard 2.0 as well as the latest versions of Net explicitly (right now 6/7). System.Formats.Tar is unfortunately not available for netstandard, only for net6/net7: https://learn.microsoft.com/en-us/dotnet/api/system.formats.tar?view=net-7.0&viewFallbackFrom=netstandard-2.0.

2. The reason the timeout doesn't trigger in this scenario is that the timeout is checked by the resource governor's CheckResourceGovernor method before attempting each attempt to extract an item from an archive. If a call to another library ends up stalling, there's no interim call that checks the resource governor. This aspect should be possible to address, but might require some significant changes to the timeout check works and I'm hoping I can develop a simpler workaround for this issue before taking that on - I have noticed for example that calling the TotalSize property that is used as a sanity check at the top of the tar extract method can cause a stall, but if I omit that call it will enumerate the entries before stalling later, so there may be a way to work around this case.

[gfs]

#130 should resolve the stall behavior. This archive will now emit an Overflow Exception from the resource governor when the byte limit is hit (and timing should work as well).