[GRASS5] [bug #4244] (grass) segmentation library short read()s

[Hamish]

> > this bug's URL: http://intevation.de/rt/webrt?serial_num=4244
> > -------------------------------------------------------------------
> > 
> > Subject: segmentation library short read()s
..
> > as many have noticed, sometime after 6.0 was released modules using
> > the segmentation library started to see read errors. After fixing
> > the reported error message in pagein.c we see that a short read is
> > happening: WARNING: segment_pagein: short count during read(), got
> > 4076, expected 4096 WARNING: segment_pagein: short count during
> > read(), got 1004, expected 1024 ...
> > 
> > seems to be consistently short 20 bytes.
> 
> It is caused by this change to zero_fill():
> 
> 	RCS file: /grassrepository/grass6/lib/segment/format.c,v
..
> 	revision 2.1
..
> Specifically, the line:
> 
>     if ( lseek(fd,nbytes-1,SEEK_SET) < 0 ) { 
> 
> should use SEEK_CUR rather than SEEK_SET, as it is supposed to be
> writing nbytes from the current position, not from the start of the
> file.

I can confirm that change gets rid of the warnings and the r.univar 
sum of values now matches the 6.0.2 value.


> Note that there is a 20-byte header (5 "int"s) at the start of the
> file, which would explain why the read() is always 20 bytes short
> (zero_fill() is always called just after the header has been written).
> 
> I'm not sure why that header is there in the first place; segment
> files aren't supposed to be shared across different processes, are
> they?

Don't know. I wouldn't have thought so.


Hamish