tridge at au1.ibm.com
Thu Jun 15 05:08:24 GMT 2006
(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
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.
More information about the samba-technical