[PATCH] Fix for bug 11522: smbd can't create or open a stream name on the root directory of a share.

[Jeremy Allison]

On Thu, Sep 17, 2015 at 11:23:08AM -0700, Jeremy Allison wrote:
> On Thu, Sep 17, 2015 at 08:49:28AM -0700, Jeremy Allison wrote:
> > On Thu, Sep 17, 2015 at 02:06:26PM +0200, Ralph Böhme wrote:
> > > On Thu, Sep 17, 2015 at 06:47:28AM +0200, Ralph Böhme wrote:
> > > > On Wed, Sep 16, 2015 at 04:20:09PM -0700, Jeremy Allison wrote:
> > > > > An interesting log from an OEM lead me to look
> > > > > into what happens when a client tries to create
> > > > > a file named :streamname (no path, just stream :-).
> > > > > 
> > > > > On Windows this creates :streamname on the top
> > > > > level directory of the share. For Samba, we
> > > > > return NT_STATUS_OBJECT_NAME_NOT_FOUND :-(.
> > > > > 
> > > > > Fix attached (OK the first patch is a code
> > > > > cleanup I noticed along the way). Includes
> > > > > a regression test which we now pass !
> > > > > 
> > > > > Review + push appreciated.
> > > > 
> > > > rb by me & will push.
> > > 
> > > autobuild keeps failing in
> > > 
> > > [306(1259)/1872 at 28m49s] samba3.base.dir2(nt4_dc)
> > > smbtorture 4.4.0pre1-DEVELOPERBUILD
> > > Using seed 1442476151
> > > Creating 1000 files
> > > num_seen = 2002
> > > num_seen = 1002
> > > num_seen = 1001
> > > (../source4/torture/basic/dir.c:148) entry count mismatch, should be 1000, was 1001
> > > UNEXPECTED(error): samba3.base.dir2.dir2(nt4_dc)
> > > 
> > > A local make test works ok though.
> > 
> > I'll take a look. Might be a stream now being created
> > that wasn't before. The fix is certainly correct.
> 
> OK. Might be that the smbclient test which is run
> before samba3.base.dir2 leaves the :foobar stream
> on the base directory of the [tmp] share and doesn't
> get deleted (there's no stream delete in smbclient).
> Still shouldn't be visible to a old SMB1 directory
> list though. I might try replacing the smbclient
> test with a smbtorture test that explicitly deletes
> the stream on the toplevel share directory.

Reproduced it locally, so it's probably the 'dead
stream' issue. You have to run a full 'make test'
to ensure the tests are run in sequence. Easiest
fix might be to use a new share for the test, so
it doesn't care about dead entry on [tmp]..