Correct handling of isRecycled

Matthieu Patou mat at
Tue Nov 8 15:53:58 MST 2011

Hi Metze & Tridge,

Any news on this ?


On 03/11/2011 22:26, Matthieu Patou wrote:
> On 03/11/2011 18:15, Stefan (metze) Metzmacher wrote:
>> Hi Matthieu,
>>> I pushed here:
>>> Windows 2008r2 insists on having a compatible schema when joining a
>>> domain, and for all objects that are tombstones or becoming tombstones
>>> it hads the isRecycled=TRUE attribute if FL<2K8R2 or if the recycle-bin
>>> is not enabled. For already deleted objects or objects deleted on pre
>>> Windows 2008r2 (ie. Windows 2003r2) this attribute is added while doing
>>> the replication (initial or regular one).
>>> With this patches, Samba adds this attributes to tombstones objects if
>>> the schema support the isDeleted attributes (commit a80863db) while
>>> deleting objects or during replication (initial and regular).
>> But with this patch we always add isRecycled: TRUE if it's not already
>> there when we get a change from another dc, there's no check for the
>> functional
>> level.
> Hum I think I forgot that isRecycled is not set even when the object 
> is just in the DELETED status by Windows and Samba.
> I changed to add a small test for the recycle-bin so that.
> If FL <2K8R2 then the recycle-bin enabled is always false, if FL >= 
> 2K8R2 we test if the feature is enabled.
> If not enabled that's the way to go (add isRecycled = TRUE)
> If enabled we don't do anything while replicating.
>>> In order to cope with current Samba setup and without requiring them to
>>> run upgradeprovision or dbcheck, the kcc-deleted task has been modified
>>> to add this attribute if supported by the schema to deleted objects 
>>> that
>>> do not have it (commit fad767b761f).
>> This commit
>> has still stuff the belongs to the full scan commit.
>> Also I'm not sure if this is the correct thing todo, as we never
>> explicitly store 'isRecycled: FALSE' and cannot find out if adding
>> isRecycled: TRUE
> Fixed too
>> is the right thing to do for the given object.
>>> I also corrected the changed I made for link pointing to deleted 
>>> objects
>>> that should not be sent, so that it takes care of the forest level
>>> (commit 21270a76b).
>> This commit
>> should be the last one (not the first one) and you should use "TRUE"
>> instead of "true",
> it's a strncasecmp as true and TRUE are two valid value.
>> as "TRUE" is stored.
>>> I also included a change for the removal of deleted of objects that are
>>> not in the Deleted Object container (commit c13e511da), I think that 
>>> the
>>> only case I know so far are site related objects and some child objects
>>> that have DONOTMOVE flag (or similar).
>>> Let me know about them.
>> I think we need a better way to detect if we want to fix an object which
>> is stored broken,
>> maybe look for attributes which should be there if the object is only
>> DELETED and not an old style TOMBSTONE.
> Well here it's not fixing it's just removing objects that are not in 
> the Deleted Object container, for sites and such it's a correct 
> behavior to have them not in the Deleted Objects container.
> Ok I think I addressed your remarks in the new version of patches in 
> my branch.

Matthieu Patou
Samba Team

More information about the samba-technical mailing list