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

[Roberto Flor]

Glynn Clements wrote:

>Request Tracker wrote:
>
>  
>
>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?
>
>  
>
The patch is quite correct; the segment file was shorter of 20 bytes
when using the lseek zero_fill.
The header is required because the segment_format just create the file,
while the segment_init initialize it.
The typical segment library usage was:
    fd=open_for_writing
    segment_format(fd,..)
    close(fd)
    fd=open_for_reading_writing
    segment_init(fd,...)
 
and the parameters are shared through the header.
The lseek zero_fill  does not really allocate the file, it just  extend
the file size, so it's  possible  a write error  later, but it's a lot
faster than writing zero bytes to a file. The write error are handled
inside segment_pageout and segment_put_row with a G_warning and a -1
return code.