tdb/tdb.c: tdb_oob() significance (when not using MMAP)

[tridge at samba.org]

dk,

 >  If we are not using MMAP for writing TDB files (using lseek & write),
 > does tdb_oob() still have any significance?

yes - it's basically an internal check for corruption. It is just as
relevent without mmap as with.

 > Since a call to lseek() & write() will expand the file if the file
 > is shorter than the length, IMHO, the out of bound check may not be
 > required.

The thing is, you don't want a write to expand the file unless you
really mean it to. Expanding the file shouldn't just happen in any old
place in tdb - it has to happen with some careful checks related to
current transactions, the header, the free list etc. So tdb_oob() is
used to ensure that you don't accidentally expand the file when its
not needed.

 >  On VMS port, we are finding some cases where the call to stat returns
 > a size smaller than the total lenght (file pointer offset + size of
 > data to be written).

I suspect that this indicates a real bug somewhere. Changing tdb_oob()
to hide this bug is not the right approach - instead you need to find
the bug :-)

Does the tdb test suite pass?

Also, does VMS have a pwrite() call? Using lseek/write is not nearly
as good as using pwrite due to race conditions on inherited file
descriptors.

Cheers, Tridge