ghisler(Author) wrote: 2021-01-11, 14:53 UTC
So do I need to check the current position, seek to the start, and then only get the data until that position?
That's the idea according to the documentation.
Personally, I would see this as the best approach. The reasoning: i would assume the majority of such cases being an IStream producer who is taking the "extra" step of explicitly setting the stream position knowingly and intentionally. (Sure, one could argue that a stream position somewhere in the middle of the stream might be an unintended artifact of some in-memory stream compositing. But then again, i would argue that such cases of leaving the stream pointer unintentionally dangling at arbitrary meaningless non-zero stream positions should be in the minority...)
This would not work with streams where the pointer is already at the start.
If the stream position is at the beginning of the stream, i guess it is safe to assume that it is a stream not sticking to the rule.
In this case, as many bytes should be read as specified as the stream size (unless Read fails sooner with S_FALSE, of course). The stream size can be obtained by invoking IStream::Stat (
https://docs.microsoft.com/en-us/windows/win32/api/objidl/nf-objidl-istream-stat). Only if the stream size is also zero, i would solely rely on the Read method returning S_FALSE to indicate end of the offered data. I can't really fathom any situation aside from software bugs where a given non-zero stream size would not correlate with the stream position where Read would fail with S_FALSE, but better safe than sorry...
This approach should hopefully minimize the chances of something going awry. There would still be problems with (hypothetical?) infinite IStreams, but that's nothing that an IStream consumer can solve in a satisfactory way.
In other words, are there streams where the pointer is somewhere in the middle, and reading beyond that point would be a problem?
I have no idea and no example of a program that produces such IStreams. In the best case, both TC and the IStream-producing program would coincidentally agree to disagree with the rule in the same way, and everything goes to plan. Otherwise, TC would write additional data (whether meaningful data or garbage) into the file that is not supposed to be part of the data offered.
I don't know enough about OLE and COM to have an understanding of how to create infinite IStreams or other IStreams with content procedurally generated upon read or copy. (Is that even possible? i don't know). And i thus can't really do anything else than make wild and possibly unfounded speculations that would run the gamut from writing infinite streams into a file until the space in the file system is exhausted up to whatever forms of crashes or freezes of whatever code that might back a particular custom IStream/ISequentialStream implementation.
