VFS and tdb_lock
Jeremy Allison
jeremy at valinux.com
Fri Sep 29 00:33:10 GMT 2000
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.
--------------------------------------------------------
More information about the samba-technical
mailing list