To release Samba 4.0 'as is'
tridge at samba.org
Mon Nov 28 22:39:01 MST 2011
> Having a second file server embedded - used only in certain
> cases and having differing semantics is a receipe for disaster,
> and not a good idea for long term stability of this release.
I am not suggesting it should be the default, but I would like to keep
the ntvfs code buildable and usable. Apart from the embedded case, it is
also the file server we have done all testing of Samba as a DC against
so far. Being able to run it by setting a config option is a good thing
I think, at the very least for debugging issues with the changeover to
the smbd based file server. It also means that existing sites running s4
as a DC are able to continue to run the file server they have been using
up to now.
It also has a very nice structure. I'd eventually like to see the smbd
file server adopt many of the structural ideas in ntvfs. I know that
won't happen soon, but it seems silly to throw all that effort in the
bin when it has a lot of good design features.
> That's a big sticking point for me. I though we'd decided
> s4 fileserver was smbd code - end of story. The details
> were how to do the integration.
> Now I hear the ntvfs/ server is coming back from the dead.
> I didn't sign on for that at all.
In past discussions I tried to make it clear that I didn't want the
ntvfs/ code to be deleted, only that the default should be the s3 smbd
More information about the samba-technical