[cifs-protocol] [REG:110051857479854] RE: Replicating deleted object procedure clarifications

[Kamen Mazdrashki]

Hi Hongwei,

You are totally right and you understood my question, thanks!

The thing is that although the comment before calling RemoveObj() describes
what should happen next,
RemoveObj() descriptions itself doesn't mention about this situation at all.
I think the documentation is not complete enough and RemoveObj() prototype
and description should
make a distinction between 'mangling object DN, state and update attributes'
and just 'update attributes'.
Now, if someone reads the description it looks like RemoveObj() will act
blindly on DSNAME given,
which should lead to deleting the object, modified already by
PerformModifyOperation() :)

Thanks,
Kamen


On Sat, May 22, 2010 at 02:40, Hongwei Sun <hongweis at microsoft.com> wrote:

>  Kamen,
>
>
>
>    For your question regarding the algorithm used in UpdateObject() , as
> documented in 4.1.10.6.9 of MS-DRSR,  I think that the RemoveObj()  was
> performed after PerformModifyOperation just to ensure the attributes on
> the deleted object conform to the invariants of a tombstone or
> deleted-object(see 3.1..1.5.5 of  MS-ADTS).   This is mentioned in the
> comments of the algorithm before RemoveObj is called.    Furthermore, as per
> 5.154 of MS-DRSR, RemoveObj procedure performs a delete operation on an
> object so the targeted object will be transformed to a deleted-object or a
> tombstone ,depending on the state of the Recycle Bin option feature.  This
> includes modifying the attributes and moving into the Deleted Container of
> its NC.  But it will not remove the objects from the directory directly.
> If the object after PerformModifyOperation already conforms to the invariant
> of deleted-object or tombstone,  the RemoveObj may do nothing to the object.
>
>
>
>   Please let me know if I understand you question properly and if you have
> further questions.
>
>
>
> Thanks!
>
>
>
> Hongwei
>
>
>
>
>
>
>
> *From:* cifs-protocol-bounces at cifs.org [mailto:
> cifs-protocol-bounces at cifs.org] *On Behalf Of *Kamen Mazdrashki
>
> *Sent:* Tuesday, May 18, 2010 7:33 AM
> *To:* Interoperability Documentation Help; cifs-protocol at samba.org;
> pfif at tridgell.net
> *Subject:* [cifs-protocol] Replicating deleted object procedure
> clarifications
>
>
>
> Dear Dochelp,
>
>
>
> I am currently trying to refactor Delete object implementation in Samba and
> I need some help
>
> with algorithm used for deleting objects and how the deletion is replicated
> to other DCs.
>
>
>
> Reference:
>
>  ProcessGetNCChangesReply [MS-DRSR] -
> http://msdn.microsoft.com/en-us/library/dd207758(v=PROT.13).aspx
>
>     UpdateObject [MS-DRSR] -
> http://msdn.microsoft.com/en-us/library/dd207780(v=PROT.13).aspx
>
>  Delete Operation [MS-ADTS] -
> http://msdn.microsoft.com/en-us/library/cc223480(v=PROT.13).aspx
>
>
>
> Consider following sutiation:
>
> 0. We have two DCs configuration.
>
>     We have an OU object with following props:
>
>       dn: OU=TEST_DELETE_0417,DC=samba,DC=devel
>
>       objectGUID: b7f1b90d-d247-45b7-87fb-f6bc916bd729
>
>
>
> 1. We delete this OU on DC1. The state of this object on each dc should be
> as follows:
>
>   DC1:
>
>       dn:
> OU=TEST_DELETE_0417\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd729,CN=Deleted
> Objects,DC=samba,DC=devel
>
>       objectGUID: b7f1b90d-d247-45b7-87fb-f6bc916bd729
>
>       isDeleted: TRUE
>
>       isRecycled: TRUE
>
>   DC2:
>
>       dn: OU=TEST_DELETE_0417,DC=samba,DC=devel
>
>       objectGUID: b7f1b90d-d247-45b7-87fb-f6bc916bd729
>
>
>
> 2. Replication is triggered from DC1 to DC2.
>
> Now, according to UpdateObject() procedure, we will identify that Object's
> DN has changed from
>
> "dn: OU=TEST_DELETE_0417,DC=samba,DC=devel"
>
> to "dn:
> OU=TEST_DELETE_0417\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd729,CN=Deleted
> Objects,DC=samba,DC=devel".
>
> Hence we will modify object's DN (calling PerformModifyDNOperation()
> operation).
>
> Which will make this object a Deleted-object right?
>
> While progressing further in UpdateObject() procedure, we will check and
> see, that 'isDeleted'
>
> attribute value is TRUE, so we shall call RemoveObj() procedure. At this
> point I am a little bit puzzled as
>
> there are two possible outcomes from this procedure:
>
> 1. Object's RDN should be transformed to a delete-mangled RDN. So we should
> end with an RDN like:
>
>  TEST_DELETE_0417\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd72\0ADEL:b7f1b90d-d247-45b7-87fb-f6bc916bd72
> right?
>
> 2. Or, as the object is already under "Deleted Object" container (moved
> there by previous call to PerformModifyOperation()),
>
> RemoveObj() procedure should delete it further - i.e. if the object is a
> Tombstone, it will be completely removed.
>
>
>
>
>
> Sorry that my description gets so messy.
>
> Basically what UpdateObject() states is that first we should execute
> PerformModifyOperation() and then RemoveObj().
>
> Which is a little bit confusing, as PerformModifyOperation() will turn the
> object into a Deleted-object.
>
> Calling RemoveObj() later will actually act on already modified object, so
> I wonder - how does RemoveObj()
>
> knows that we just converted the object and this object should not be
> completely removed?
>
>
>
> Another possibility is for PeformModifyOperation() to determine that target
> DN will move the object under
>
> "Deleted Objects" container, and in this case to modify only Attribute
> values on the object, but not to call
>
> PerformModifyDNOperation() operation?
>
>
> --
> CU,
> Kamen Mazdrashki
> kamen.mazdrashki at postpath.com
> http://gitweb.samba.org/?p=kamenim/samba.git;a=summary
> -------------------------------------
> CISCO SYSTEMS BULGARIA EOOD
> http://www.cisco.com/global/BG/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20100523/e2d67abe/attachment-0001.html>