Question

Interesting problem I ran into recently:

I implemented a Stream class (a wrapping stream for a custom streaming pipeline component) and some later testing had my pipeline throwing an exception. The exception was thrown from a call to Seek which I had hardcoded to throw a NotImplementedException due to my stream being a forward-only, non-writable stream implementation (CanSeek and CanWrite returning false, Position:set throwing an exception, nothing unusual). The call to Seek was coming from unmanaged code, so I couldn’t really debug into it too much. All I could really tell was that Seek was being called on my Stream implementation even though I had CanSeek returning false and the user wasn’t even checking CanSeek.

What’s up with that?

Answer 1

All the answers were found here: Implementing a Seek Method in a Managed Streaming Pipeline Component

It turns out that way back when, there was no Position property. So the way to get the current position of the stream pointer was to call Seek( 0, SeekOrigin.Current );

Fascinating. The old new thing again.

That page gave the Seek implementation required:

override public long Seek(long offset, SeekOrigin origin)
{
   long pos = -1;

   switch(origin)
   {
      case SeekOrigin.Begin :
         pos = offset;
         break;
      case SeekOrigin.Current :
         pos = Position + offset;
         break;
      case SeekOrigin.End :
         break;
   }

   // We generally disallow seeking of the stream
   // However, in unmanaged code, many people use Seek(0,CURR) to retrieve    // the current position
   // Special case (that is, if Seek does not change position, do not 
   // throw an exception)
   if (pos==Position)
   {
      return pos;
   }
   else
   {
      throw new NotSupportedException("ForwardOnlyEventingReadStream does not support Seek()");
   }
}

And that was the entire solution. Yay!