That is interesting. I would be very interested in a full stacktrace when that happens, because AFAIK it checks the correct APIs for this, for example (from ProtoReader.Seek
).
if (source.CanSeek)
{
source.Seek(count, SeekOrigin.Current);
// ...
}
else
{
// ... does it the hard way, even if that means a Read loop
}
So no, it doesn't currently have an option for this because it trusts the streams to tell the truth. Of course, it could simply be a bug on my part, hence the request for a stacktrace.
If this is a genuine "thing", it would probably be possible to add such a mechanism.
Edit: yup, this is a bug in BZip2InputStream.cs
in SharpZipLib; it has:
/// <summary>
/// Gets a value indicating whether the current stream supports seeking.
/// </summary>
public override bool CanSeek {
get {
return baseStream.CanSeek;
}
}
but it also has:
/// <summary>
/// Set the streams position. This operation is not supported and will throw a NotSupportedException
/// </summary>
/// <param name="offset">A byte offset relative to the <paramref name="origin"/> parameter.</param>
/// <param name="origin">A value of type <see cref="SeekOrigin"/> indicating the reference point used to obtain the new position.</param>
/// <returns>The new position of the stream.</returns>
/// <exception cref="NotSupportedException">Any access</exception>
public override long Seek(long offset, SeekOrigin origin)
{
throw new NotSupportedException("BZip2InputStream Seek not supported");
}
So, it can never seek, but it claims it can if the base stream can.
It should have reported false
instead of echoing the base-stream's CanSeek
.