> > Thanks for catching this. > > > > One question though: did you test reconnection to the same server with > > reset USN? I'm sure it will work in terms of refreshing the local > > database, I'm just not entirely certain that the srv_opts->last_usn will > > be set to current value later in the code (which would mean the next > > reconnection to the same server wouldn't start refreshing the data). If > > the test passes, consider the patch Acked. > > If the local last_usn value is *lower* than what's on the server it is > fine, nothing bad will happen and it is expected to happen from time to > time as we read usn values only from user/group objects, but an admin > may have modified objects we never pull. > > Not sure what you mean about the next reconnection. Unless the last_usn > on the (same) server is lower than we have on record we do *not* want a > full refresh. We need a full refresh only if the server is different > (this in all cases independetly of the valu of last_usn) or if the same > server shows a lower value.
I think you misunderstood me. My concern about Stephen's patch was a little different - I wasn't sure if the last_usn he sets to 0 shouldn't be left as is (it is not set anywhere else, which would leave it 0 and if reconnecting to the same server again, the need for full refresh won't be even detected). Looking at my original code, I see the same thing in sdap_id_op.c, including similar error Stephen fixed by his patch (setting current_srv_opts and rewriting them later). Let me do some testing and get back to you. Thanks Jan
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/sssd-devel
