Is it safe to use Stream.Seek when a BinaryReader is open?

Question

Because of the under the hood buffering strategy of BinaryReader, it is unclear to me whether is it ok or not to read an offset stored in a stream, then reposition the stream at this offset to resume the streaming.

As an example, is the following code ok:

using (var reader = new CustomBinaryReader(inputStream))
{
   var offset= reader.ReadInt32();
   reader.BaseStream.Seek(offset, SeekOrigin.Begin);

   //Then resume reading the streaming
}

Or should I close the first binary reader before Seeking the stream and then reopen a second reader ?

int offset;
using (var firstReader = new CustomBinaryReader(inputStream))
{
   offset= firstReader.ReadInt32();
}
inputStream.Seek(offset, SeekOrigin.Begin);
using (var secondReader = new CustomBinaryReader(inputStream))
{
   //Then resume reading the streaming
}

Meliamelic

Answer 1

BinaryReader does use a buffer but only to read enough bytes from the base stream to convert a value. In other words, ReadInt32() will buffer 4 bytes first, ReadDecimal() will buffer 16 bytes first, etcetera. ReadString() is the trickier method but it has counter-measures as well, a string is encoded in the file by BinaryWriter which writes the string length first. So that BinaryReader knows exactly how many bytes to buffer before converting the string.

So the buffer is always empty after one of the ReadXxx() method returns and calling Seek() on the BaseStream is fine. Also the reason that Microsoft didn't need to override the Seek() method.

The cautionary note in the MSDN article is appropriate, you certainly will read that "offset" value more than once if you call a ReadXxx() method after the Seek() call. I however assume that was entirely intentional.

Officialism

Hans, why would you read the offset value more than once if calling a ReadXxx() method after the Seek() call? Won't the BinaryReader just refill the buffer and give you the correct values? Unless, of course, the offset has a value equal to the location of the written offset itself--then you'll just end up right back where you started. – Vibrations

Also the reason that Microsoft didn't need to override the Seek() method. Did you mean to write more here, or not? The sentence reads like you are going to say something more, but instead end it. – Exemplification

That's a question that's worth a click on the Ask Question button. – Officialism

Answer 2

I would say that it is not always safe (although it might be safe in some cases).

The Microsoft documentation for BinaryReader.BaseStream explicitly states:

Using the underlying stream while reading or while using the BinaryReader can cause data loss and corruption. For example, the same bytes might be read more than once, bytes might be skipped, or character reading might become unpredictable.

So I would avoid it.

(Interestingly, there's a BinaryWriter.Seek() method, but no BinaryReader.Seek().)

Zelaya

Answer 3

In my experience so long as you are using them both synchronously and no other thread is doing anything with the stream then it works perfectly fine.

I do that extensively in applications I have written to work with binary file formats and have never encountered an issue.

Scurry