Issue 264 in glassdb: Current Implementation of ZipReadStream>>#getFirstBuffer makes assumption on ReadStream>>#next: behavior

Status: Accepted
Owner: [hidden email]
Labels: Type-Defect Priority-Medium GLASS-Server Version-2.4.x  
Milestone-1.0-beta.8 Package-Core

New issue 264 by [hidden email]: Current Implementation of  
ZipReadStream>>#getFirstBuffer makes assumption on ReadStream>>#next:  
behavior
http://code.google.com/p/glassdb/issues/detail?id=264

The current implementation of ZipReadStream>>#getFirstBuffer

getFirstBuffer
        "Get the first source buffer after initialization has been done"
        sourceStream == nil ifTrue:[^self].
        source := sourceStream next: 1 << 16. "This is more than enough..."
        sourceLimit := source size.


relies on the assumption (from Squeak) that ReadStream>>#next:
will silently just pick the maximum for read:

"in Squeak, ReadStream>>#next. "
next: anInteger
        "Answer the next anInteger elements of my collection.  overriden for  
efficiency"

        | ans endPosition |

        endPosition := position + anInteger  min:  readLimit.
        ans := collection copyFrom: position+1 to: endPosition.
        position := endPosition.
        ^ans

However, GemStone AnsiReadStream throws an error.

This happens in ZipFileMember>>#uncompressDataTo:

>> decoder := ZipReadStream on: stream.

because getFirstBuffer is called with the original stream that is
an AnsiReadStream, ignorant of the supprising Squeak Behavior

Updates:
        Labels: -Milestone-1.0-beta.8 Version-1.0-beta.8

Comment #1 on issue 264 by [hidden email]: Current Implementation of  
ZipReadStream>>#getFirstBuffer makes assumption on ReadStream>>#next:  
behavior
http://code.google.com/p/glassdb/issues/detail?id=264

(sorry, not milestoning)

Updates:
        Owner: [hidden email]
        Labels: Milestone-1.0-beta.8.7

Comment #2 on issue 264 by [hidden email]: Current Implementation of  
ZipReadStream>>#getFirstBuffer makes assumption on ReadStream>>#next:  
behavior
http://code.google.com/p/glassdb/issues/detail?id=264

Is this issue related to Issue 266? If so, the answer is to avoid mixing  
ANSIStreams and ZipStreams ... they are just plain incompatible (for now)

Updates:
        Labels: -Version-1.0-beta.8 -Milestone-1.0-beta.8.7

Comment #3 on issue 264 by [hidden email]: Current Implementation of  
ZipReadStream>>#getFirstBuffer makes assumption on ReadStream>>#next:  
behavior
http://code.google.com/p/glassdb/issues/detail?id=264

See Comment 5 in (http://code.google.com/p/glassdb/issues/detail?id=266#c5)  
Issue 266