[PATCH] CTDB recovery lock improvements

Andreas Schneider asn at samba.org
Tue Jun 14 16:48:31 UTC 2016


On Tuesday, 14 June 2016 09:18:04 CEST Jeremy Allison wrote:
> On Tue, Jun 14, 2016 at 02:54:27PM +0200, Andreas Schneider wrote:
> > On Tuesday, 14 June 2016 13:27:36 CEST Aurélien Aptel wrote:
> > > On Tue, 14 Jun 2016 09:57:53 +0200 Andreas Schneider <asn at samba.org>
> > > 
> > > wrote:
> > > > the difference might be that autobuild runs completely in memory, not
> > > > on disk!
> > > > 
> > > > However we try to avoid adding more sleeps in the source code
> > > > especially so long ones. Autobuilds alread runs 2,5 hours we don't
> > > > need to extend it.
> > > 
> > > It's an extra 6 seconds but I see what you mean.
> > > 
> > > > So a check (stat()) in a loop with usleep() is preferred.
> > > 
> > > How can I reliably check that the DOS mode flag has been set with
> > > stat()? Flags can be stored in tdb IIUC.
> > 
> > Oh, then I think it might be a good idea to write a tool which can check
> > the tdb then.
> > 
> > With that tool, start by creating a test which sets dos mode with
> > smbclient
> > and verify it with the tool that it is correctly written. If we also store
> > the owner and group of the file in that tdb, we could finally verify that
> > 'force user' works correctly ...
> 
> Actually, now the client code supports the POSIX WHOAMI call,
> getting the token back that smbd is using remotely is quite
> easy (see the code I added recently for that).

Well the problem is we do not know if Samba writes a file to disk as the 
correct user. We fake everything with cwrap, so what we end up is writing 
files as the user who started selftest. But if we store information about the 
user in a tdb file too, we could read the file to verify that is half worked. 
I think a way without doing that through smbd would be more correct for a test 
:)


	-- andreas

-- 
Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             asn at samba.org
www.samba.org



More information about the samba-technical mailing list