On Thu, 2008-01-10 at 18:25 -0800, Howard Chu wrote: > Andrew Bartlett wrote: > > On Wed, 2008-01-09 at 18:37 -0800, Howard Chu wrote: > >> 'way back I recall explicitly allowing this case, but the current backend code > >> doesn't. I think it's worth filing an ITS for this. > > > > Done. ITS#5319 > > Preliminary fix in HEAD... For renames that just change the case of the DN, > there's no further issues. Great. This seems to work nicely. > >> As for renaming an entry to exactly the same DN, I could go either way. If we > >> ignore it and silently return success, it will still generate replication > >> traffic, which may or may not be desired. > > > > Naturally, I would prefer that it behave as AD does, and I think that it > > would ensure things remain tested (less differing behaviours). I don't > > expect people do this kind of rename while expecting a NOOP, so > > replication traffic seems reasonable. > > Except that it doesn't make sense at the moment. Since renaming to exactly the > same DN is treated as a no-op, the entry's modifyTimestamp, modifiersName, and > entryCSN are not updated. (I.e., the entry is completely untouched.) There > really should not be a replication event in this case. Either that, or we have > to actually write the entry and update these operational attributes, so it's > not really a no-op any more. I'm happy if as the client requests an operation here, that we perform exactly that operation. It might not change the end result in the DN or the RDN attribute, but the client clearly asked for a change, so why not treat it like all other changes? Does that make sense? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc.
Attachment:
signature.asc
Description: This is a digitally signed message part