Thoughts on how to communicate to VFS functions that a CREATE is occurring

Richard Sharpe realrichardsharpe at
Mon Apr 4 15:26:56 UTC 2016

On Mon, Apr 4, 2016 at 7:36 AM, Volker Lendecke
<Volker.Lendecke at> wrote:
> On Mon, Apr 04, 2016 at 07:26:46AM -0700, Richard Sharpe wrote:
>> On Sun, Apr 3, 2016 at 11:15 PM, Volker Lendecke
>> <Volker.Lendecke at> wrote:
>> > On Sun, Apr 03, 2016 at 10:26:40AM -0700, Richard Sharpe wrote:
>> >> Well, we have implemented it, but it involved changes in Samba that I
>> >> would like to get rid of.
>> >>
>> >> The feature is sharding of directories across multiple servers in a
>> >> cluster and using DFS referrals to get clients connected to the
>> >> correct server in the cluster.
>> >>
>> >> When a client asks you for a DFS referral for the directory that is on
>> >> the node they are connected to (which they do, from time to time) we
>> >> need to return the correct information.
>> >>
>> >> To do all of the above successfully, we have found that we need to
>> >> know, in the VFS layer (and particularly, in STAT, which is pretty
>> >> much the earliest VFS function called) whether we were called for a
>> >> CREATE or for something else.
>> >
>> > What is the sequence of events? You get a SMB_CREATE, and you return a
>> > PATH_NOT_COVERED. Then you get an ioctl that asks for the target path.
>> > Is that right?
>> Yeah, that's the sequence.
>> > Intercepting create_fn is not sufficient, because it is called from other
>> > highlevel SMB requests too?
>> That too. However,. more importantly, things like stat_fn is called
>> before create_fn is called.
> And you can't succeed with the stat_fn and later in the create_file_fn
> return either success or NOT_COVERED?

I don't think that is going to work because there are a lot of places
that end up calling the stat_fn that are unrelated to CREATE, although
most of those will never be called if a DFS referral was sent to the

> Maybe it's time that we take a look at your patches. Do you also have
> testcases covering your requirements?

Not yet ...

Richard Sharpe

More information about the samba-technical mailing list