VFS and tdb_lock

[Jeremy Allison]

Brad Sahr wrote:
> 
> Jeremy,
> 
> I can't reproduce the problem when the VFS is not involved, and this is what
> I expected.
> 
> I think that my VFS is doing something to cause the open/locking code to get
> confused. My concern starts with the call to vfs_file_exist() at the start
> of open_file_shared() in smbd/open.c. In my VFS, the file does not actually
> exist on disk (yet) so I fill out the stat struct as best as I can - getting
> some file information from a remote source. Eventually, the tdb locking code
> uses the device and inode information within the stat struct to perform
> locking. I'm assuming that these are being used as a means to have some
> unique information for the lock - correct?

Ah - ok - this now makes sense. The vfs_file_exist() call needs to
return either False, or a valid dev/inode pair that is used to
create the key for the tdb hashchain lock. If you fake this up
and then change the dev/inode pair later on then the code will
probably break in the way you've seen.

Remember, your vfs is supposed to act like a POSIX filesystem,
and they don't do that.

> The locking code doesn't actually perform any file I/O? If it did, it should
> come through my VFS.

The tdb locking code will do POSIX fcntl lock calls onto
a *local* filesystem - it's not supposed to come through
your vfs.

Ok - Andrew - panic over (ignore my phone call :-), the
tdb locking rewrite logic is correct.... :-).

Hope this helps,

	Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------