Looks like Microsoft broke their C run-time by migrating some C routines to their corresponding large file version that have a different behavior than what we used to.

The issue is that read_stream is read using the C FILE pointer and it reads the first N bytes of the file into a buffer and moves the internal pointer to the end of the file. When you call `go` it actually does not update the actual location of the pointer, just the location in the buffer. So when we start retrieving we do not use the buffer but the direct low level access to the file except that the internal pointer is at the end not at position 0 so trying to read more returns 0 byte. 

The problem lie in the call to the C function fseek which is now implemented like fseeki64 was in previous runtime which did not update the cursor position. If we had used fseeki64 in our runtime you would also have the same problem with older versions of the C compiler.

There are no good workaround for this problem apart from asking Microsoft to fix the problem if they agree it is indeed an issue. Anyway any of the following will work to some extent:
#1 - never use any read operation from the FILE class while mixing it with storable as they do not use the same API to read.
#2 - if you need to read data you could wrap the C `read` API instead.
#3 - each time we query the file descriptor of a FILE we reset the position explicitly. It will work once when going from FILE to file descriptor but then trying to read again using FILE will not work as you expect (buffer will still at the some position) so this opens the door to more problem.

We have tested workaround #3 but it might be best for you to use #2 as you are more in control on how you read your storables.