Please review: [389 Project] #47314: Winsync should support range retrieval
by Noriko Hosoi
https://fedorahosted.org/389/ticket/47314
https://fedorahosted.org/389/attachment/ticket/47314/0001-Ticket-47314-Wi...
Bug description: AD returns up to MaxValRange number of multi-
valued attribute values in one search. If more attribute values
exist, subtype ";range=0-(MaxValRange?-1)" is added to the type.
AD Client (DS in this case) has to repeat the search with
";range=MaxValRange?-*" then ";range=(2*MaxValRange?)-*" and so on
until the values with the subtype ";range=low-*" are returned.
Windows Sync plugin did not support the range search.
Fix description: This patch implements the range search for the
multi-valued attribute.
In addition,
1) For the search request, AD returns an attribute with no values
if it was deleted on the AD side even if the delete is one of the
multi-valued attributes. Windows Sync code was always adding the
attribute to the entry's e_deleted_attr list. This patch stops it
if there are more attributes having the same type existing in the
entry.
2) slapi_entry_attr_get_* APIs call slapi_entry_attr_find and set
the return value from the function to the value to return from the
APIs. slapi_entry_attr_find returns -1 if it fails to find the
attribute, which was returned if the type did not exist in the entry.
This patch stops it and let slapi_entry_attr_get_* APIs return the
default return value 0 in case slapi_entry_attr_find fails to find
the type.
10 years, 8 months
Please review: [389 Project] #415: winsync doesn't sync DN valued attributes if DS DN value doesn't exist
by Noriko Hosoi
https://fedorahosted.org/389/ticket/415
https://fedorahosted.org/389/attachment/ticket/415/0001-Ticket-415-winsyn...
Bug description:
2 case were fixed.
1) A group on AD has a member which is not a target of windows
sync and exists only on AD. The member value in the group is
synchronized to DS. If an operation is executed on AD so that
the member is replaced with other members which are the target
of the windows sync, the new member values are not synchronized.
2) If a group on AD and DS have members which are local and are
not synchronized and the members are removed in the group on
the other side, the delete operation is synchronized and
deletes all the members including the local members.
Fix description:
1) In windows_generate_update_mods, even if a sync'ed member value
in a DS entry is not the target of windows sync and it is does
not exist on DS, a following modify operation including the member
value is proceeded by confirming the existence on AD.
2) AD->DS: in windows_map_mods_for_replay
DS->AD: in windwos_generate_update_mods
added the code to check if an attribute is completely deleted on
one side, then the each value on the other side is in the sync
scope or not. Put the value to the mod for the delete only if
the value is in the sync scope.
10 years, 8 months
please review coverity fix
by Mark Reynolds
I added an unnecessary NULL check that caused a coverity error, so I
removed it:
2328 to the poll list */
At conditional (1): "pb->pb_conn" taking the false branch.
CID 13182: Dereference after null check (FORWARD_NULL)Comparing
"pb->pb_conn" to null implies that "pb->pb_conn" might be null.
2329 if(pb->pb_conn && pb->pb_conn->c_opscompleted == 0){
Thanks,
Mark
--
Mark Reynolds
389 Development Team
Red Hat, Inc
mreynolds(a)redhat.com
10 years, 8 months