tdb_reopen

[Andrew Tridgell]

Jim,

(CCd to samba-technical, hope you don't mind)

 > The question both Herb and I are asking is: why does it it matter if the 
 > device no. or inode have changed?  Any thoughts on this?

It matters for two reasons.

1) because tdb_reopen() does not re-read the tdb header. When you
   initially open a tdb, the code reads the header to determine things
   like the hash size, byte order etc. That information is stored in
   the tdb_context structure, and it is vital that the information
   match the structure of the tdb on disk.

2) because it could indicate that some processes are still using the
   old tdb (even if it is unlinked) and some will be using the new
   one. The point of a tdb is that it is a persistent shared store
   between processes. If different processes use a different file then
   it loses the 'shared' property, which could easily lead to data
   corruption (think what would happen if this is the locking db)

I don't understand under what circumstances you'd want to continue
when the dev/inode has changed on a tdb_reopen(). You could get around
(1) by re-reading the header and validating it, but (2) is much
harder.

Also note that on some platforms we could avoid calling tdb_reopen()
at all. It's mostly needed for broken platforms that don't have a real
pread()/pwrite() system call. On those we simulate pread()/pwrite()
using lseek(), which doesn't work unless you re-open the file
descriptor after a fork(), as the silly posix fork() semantics leave
us with the seek pointer shared on file descriptors, which means we
would have a corruption race condition if we didn't close and re-open.

Cheers, Tridge