On Sat, Apr 12, 2003 at 11:07:11PM +0200, Andreas Mohr wrote:
Hi all,
the OLE storage code basically disabled itself, by doing a READ_HEADER; in STORAGE_get_pps_entry(). This READ_HEADER uses -1 as block number for STORAGE_get_big_block() (in order to retrieve the storage header block). And if you look at the SetFilePointer() in STORAGE_get_big_block(), you might notice that (n+1)*BIGSIZE for some strange reason evaluates to 0, for n == -1. Thus, SetFilePointer() seeks to position 0 to read the storage header.
And now I'm terribly sorry to tell you that STORAGE_get_big_block() did a if (!SetFilePointer( hf, (n+1)*BIGSIZE, NULL, SEEK_SET )) { WARN(" seek failed (%ld)\n",GetLastError()); return FALSE; }
Sounds like SetFilePointer() is *supposed* to return 0 if it seeks to position 0, eh?
In other words:
- fix blatantly wrong SetFilePointer() calls
The 16bit storage code is probably not safe to work with, for instance saving is probably not working.
It should call forward to the 32bit storage code, which I think is more correct.
Ciao, Marcus
-
Marcus Meissner