Tar entries with unrecognized entry type codes are silently ignored

[RobLinux]

Steps to reproduce

1. Open tar file using TarInputStream ts = new TarInputStream(fs, Encoding.UTF8)
2. Read first entry while(ts.Position != ts.Length && (tarEntry = ts.GetNextEntry()) != null)
3. Try to get buffer to first and only file
4. File is attached

Expected behavior

Get first and only file name and buffer

Actual behavior

The first entry is not read correctly, cannot get the name and the tar is directly completely read

Version of SharpZipLib

1.3.3

Obtained from (only keep the relevant lines)

• Package installed using NuGet

Media_1 - Copy_2.zip

[RobLinux]

Seems like tar-cs and SharpCompress can read it.

[piksel]

I just looked at the file briefly, and it contains invalid data at the end, that shouldn't matter, but it indicates that it has been corrupted in some way. To be clear, what you are saying is that it doesn't find the first entry in the file? Or do you get an exception?

[piksel]

Output from archivediag:
https://pub.p1k.se/sharpziplib/archivediag/Media_1%20-%20Copy.tar.html

[piksel]

All tar entries have a typeflag that specifies what type of entry it is. For regular files, this should be set to 48 (the ASCII value of '0'). But in the supplied sample file, the only entry has a type flag of 87, or ASCII W which SharpZipLib have no idea how to handle. In fact, I can find no tar docs that specify what kind of entry W would be... This is the output from gnu tar:

❯ tar -tvf repro/samples/issue-697.tar
?rw-r--r-- mobile/users 104704 1970-01-01 01:00 isinV6rtZPprvhi24LF4maLLZsPYO-gcxbqPiVOc1Jk= unknown file type ‘W’

Several vendor types is defined in the star man page, including 'V' and 'X', but no 'W':
https://www.systutorials.com/docs/linux/man/5-star/

This is why it just skips the entry, but ideally we should provide a way to iterate over all entries, treating them as normal files (giving the consumer a chance to handle them). At the very least, there should be some kind of indication that unknown entries are being encountered.
That would be harder to do in TarInputStream but for TarArchive it should just be a matter of emitting a progress event.