Andrew Bartlett abartlet at samba.org
Wed Mar 9 00:12:33 MST 2011

On Tue, 2011-03-08 at 09:29 +0100, Volker Lendecke wrote:
> On Tue, Mar 08, 2011 at 07:28:31AM +1100, Andrew Bartlett wrote:
> > It would be good to understand exactly how big a change this would be,
> > and how many bugs we have had in this area in the past.  The NTSTATUS
> > trick is quite disruptive to the code - but was the right thing to do at
> > the time when NTSTATUS was new and this bug occurred often.  
> The last one was for example Bug 7066, fixed with c6b5136.
> My problem is that I don't dare touching the passdb
> interface to change it to NTTIME without this protection.
> Others are much more careful than I am, so for others this
> is not a problem. We can certainly leave the pdb interface
> at unix times forever, we have lived with it for quite a
> while. 

I certainly support bringing passdb to NTTIME, it's a quite important
improvement that both pdb_ads and pdb_samba4 (which I do hope to revive)
need, and I understand your desire not to be bitten by the type change

I'm not as confident as you that this is a small change however, and
would like to see the full extent of the patches (or an analysis of it)
before we agree to the change.  

> And, this will be mainly a Samba3 issue that can be
> done step by step. Samba4 does not have to adopt this.

I strongly disagree on this point.  We must never again introduce Samba3
or Samba4 only types, or special coding rules.  Any rules we choose to
adopt we must adopt and honour across the entire project, because it is
the stated aim of the team that there be no more 'samba3/samba4', but
one Samba, and that means we need a consistent coding standard. 

On a practical level, tools like PIDL and utility libraries are very
much in common, and deal with these types, and we must not take any
steps that make it harder continue bringing code in common. 

Andrew Bartlett

Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

More information about the samba-technical mailing list