Ticket #138 (new defect)

Opened 5 months ago

Last modified 5 months ago

LengthTrackingStream CanSeek returns true, but cannot set position

Reported by: Philipp Sumi <sumip@…> Owned by: serialseb
Priority: low Milestone:
Component: Core - Pipeline Version:
Keywords: Cc:
Time remaining: 1d Blocked By:
Time spent: 1d Time planned: 1d
Blocking:

Description

Attempting to set the position throws an exception, although the stream advertises itself as seekable.

Attachments

Change History

Changed 5 months ago by Philipp Sumi <sumip@…>

Correction: The issue appears to be in the underlying HistoryStream?, which returns fixed values for CanSeek? and CanWrite?, ignoring its UnderlyingStream?:

public override bool CanRead? {

get { return UnderlyingStream?.CanRead?; }

}

public override bool CanSeek? {

get { return true; }

}

public override bool CanWrite? {

get { return false; }

}

there's more there: The Position property has a fixed exception (contradictory to the returned true in CanSeek?), which should probably also rely on the underlying stream:

public override long Position {

get { throw new NotSupportedException?(); } set { throw new NotSupportedException?(); }

}

Changed 5 months ago by serialseb

  • priority changed from blocker to low

It's by design. The HistoryStream? is there to provide seeking through the Seek method when the undelrying stream doesn't have such capacity, to support codecs that need some seeking support (such as multipart readers)>

What are you trying to do?

Changed 5 months ago by Philipp Sumi <sumip@…>

I have generic helper methods that handle streams of any type in different situations. If the stream advertises that it can seek, the position is automatically adjusted. This breaks with OR, as the HistoryStream? class only supports seeking from the current position, not from the beginning. My helper class is not aware of OR, and does work with every stream class except this one.

This is a show stopper that requires me to spread try/catch hacks all over my IO code - would be nice not to have to do this :)

You wrote that the limited seeking functionality is used internally. As using a Stream that does not conform to the expected API outside of OR is bound to produce problems, it might be better to provide your required functionality through an additional interface, wouldn't it?

MSDN Docs for the Position property: The stream must support seeking to get or set the position. Use the CanSeek? property to determine whether the stream supports seeking.

Changed 5 months ago by Philipp Sumi <sumip@…>

Ended up putting the OR stream into a wrapper class that allows me to override the CanSeek? property myself. As I did this in the handler class, the hack doesn't spread too far, so I'm good. Still would recommend to have the CanSeek? property return false - I would say that in the vast majority of seeking/positioning scenarios I encountered so far, I wanted to seek from the start (which I guess why there's the Position convenience property in the first place).

Add/Change #138 (LengthTrackingStream CanSeek returns true, but cannot set position)

Author


E-mail address and user name can be saved in the Preferences.


Action
as new
 
Note: See TracTickets for help on using tickets.