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

[Glynn Clements]

Request Tracker wrote:

> this bug's URL: http://intevation.de/rt/webrt?serial_num=4244
> -------------------------------------------------------------------------
> 
> Subject: segmentation library short read()s
> 
> Hi,
> 
> 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
	Working file: format.c

	----------------------------
	revision 2.1
	date: 2005/06/30 15:48:40;  author: markus;  state: Exp;  lines: +28 -4
	Roberto Flor (ITC-irst): use lseek
	----------------------------

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.

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?

-- 
Glynn Clements <glynn at gclements.plus.com>