On Thu, Mar 17, 2005 at 02:11:29PM -0500, David L Norris wrote:
> On Thu, 2005-03-17 at 09:57 -0800, Bill Moseley wrote:
> > On Thu, Mar 17, 2005 at 08:00:43AM -0800, David L Norris wrote:
> > > On Thu, 2005-03-17 at 07:52 -0800, Carmelo Carchedi wrote:
> > > > But I just solved the problem simply spliting the index in two files.
> > >
> > > How large are the original index and prop file? If either file is
> > > larger than 2 GB you would have a similar problem.
> > I'm glad it's all working, but what do think was happening, Dave?
> I always suspect problems in the Win32 POSIX API.
Well, that's another issue.
It's just when I see a zlib error like that (a buffer error) I suspect
corrupted data -- which doesn't necessarily mean corrupted index -- it
could mean reading an incompatible index format.
Swish has to read the disk to fetch the (maybe) compressed property.
It then looks at the data for a flag indicating it's compressed, and
then reads the final uncompressed size to know how big of a buffer to
create for use while uncompressing. Then it passes to zlib the
buffer, the compressed data, and its size. So if zlib reports an
error at that point I suspect that one of those numbers was wrong --
and the most likely reason I can think of is that it's reading from
the wrong place because of mismatched code and data.
Or maybe Windows decided to replace all 10's with a 13 and a 10.
> However, 224 531 273 bytes would be 214 MB. So I'm not sure.
In Windows each byte is padded with 10 extra bytes. That's why you
have to buy those big powerful machines with lots of RAM and disk
space to do the same word processing you did five years ago. Longhorn
is going to default to 100 byte padding.
Unsubscribe from or help with the swish-e list:
Help with Swish-e:
Received on Thu Mar 17 11:32:40 2005