As I mentioned this problem is not related to unresolvable SIDs. It's related to how ACEs are laid out in the security descriptor which is sent over network and how our security descriptor decode function works. Security descriptor decode function only parse the network data and translate it to a C structure format so that it can be used by the rest of the code. Decode process does not care and has no knowledge of ID mapping so it does not matter whether a SID is resolvable or not.
Perhaps when you remove those unresolvable SIDs the ACL layout change in a way that you don't hit the bug in the decode function. Afshin Jay Anderson wrote: > In the case I used for this test, only the directory CHASTONW has the > unresolvable SIDs. I just removed the unresolvable SIDs from the directory > and tried the robocopy again, and it worked fine. That doesn't seem > coincidental to me. I've done a similar test with a full directory structure > that fails to robocopy. Every directory with unresolvable SIDs fails to have > any files copied into it (but subdirectories are copied). After manually > removing all the unresolvable SIDs the robocopy works without any errors. > Does that still make sense for what you have found? > > Thank you. > >> There seems to be a problem with our security >> descriptor decode >> function which has nothing to do with unresolvable >> SIDs. Seems >> like it's just a coincidence! >> >> Unfortunately, I cannot think of any workaround and >> since we don't >> release patches you're going to have to wait for the >> build which will >> have the fix. It could be 102 but I cannot promise >> that. >> >> Afshin > -- > This message posted from opensolaris.org > _______________________________________________ > cifs-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/cifs-discuss _______________________________________________ cifs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
