[cifs-protocol] [REG: 117070616001855] [MS-DRSR] Calling GetNCChanges with DRS_GET_TGT flag
timbeale at catalyst.net.nz
Sun Jul 9 21:43:54 UTC 2017
>> Request more detail in case of cross-partition target
We understand that it requires implementation-specific behaviour to
resolve an unknown target object when the linked attribute spans
partitions. This was answered for us in 117060115827644.
>> Target object is only recycled, as opposed to Target-object is unknown
>> (linked-attribute and you don't know the target, you send DRS_GET_TGT)
This is what I'm confused about. I inferred from the MS_DRSR Docs that
the client uses DRS_GET_TGT if it receives a linked attribute with an
unknown target object. However, the answers we received for
117060815865307 seemed to imply that DRS_GET_TGT is only used if the
target object is deleted/recycled (as opposed to simply being a
new/unknown object). Could you please clarify this - should the client
use it in either case, or is it only the deleted/recycled case where the
flag is actually required?
>> Implementation-specific statement regarding client using DRS_GET_TGT
Basically it's the following block of code in 18.104.22.168.14
ProcessLinkValue() that I find confusing/misleading.
targetObject = GetDSNameFromAttrVal( replValinf.attrTyp, replValInf.pAval)
if ((IsRecycleBinEnabled() and targetObject!isRecycled) or
(not IsRecycleBinEnabled() and targetObject!isDeleted)) then
if (DRS_GET_TGT in ulMoreFlags) then
/* nothing to do */
I don't think the proposed Docs change for 117060815865307 makes this
any easier to understand. Documentation-wise, I think there's room for
the following minor improvements:
1. Section 3.4.5 describes the ! notation. However, I couldn't see
anything that describes what happens if the object specified by the DN
doesn't exist. I would assume the attribute returned would be null.
2. If the target object doesn't exist, the current code looks like the
22.214.171.124.14 block will fall through and add a hanging link to an unknown
object. Is that the intended behaviour? A comment stating that would be
3. If there is other implementation-specific behaviour in the
126.96.36.199.14 block, then a comment stating "The actual behaviour here may
be implementation-specific" would be nice.
4. I also just noticed the above block is missing an endif.
Thanks for your help,
On 07/07/17 04:51, Edgar Olougouna via cifs-protocol wrote:
> Please provide any additional write-up as necessary. We will review
> this and follow-up.
> Implementation-specific statement regarding client using DRS_GET_TGT
> Request more detail in case of cross-partition target
> Target object is only recycled, as opposed to Target-object is unknown
> (linked-attribute and you don't know the target, you send DRS_GET_TGT)
> cifs-protocol mailing list
> cifs-protocol at lists.samba.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cifs-protocol