The list policy element has an additive attribute that determines whether the existing contents of the key will be blown away before the new entries are added. Therefore, there's a **delvalues entry in the POL file in addition to the entries, and the order of those entries matters. The PolFile.WillDeleteValue method assumes that all values under a key will be gone if there's a key-clearing entry, but that's not true in the presence of one of these lists.
So today, I adjusted that function to take into account the order of entries. It now iterates through them, updating a "will this value be here" Boolean, then returns the final value.
Then again, this probably wouldn't have mattered, since I think all ADMX files check values outside the list key for the enabled/disabled state. Oh well, you never know when some horrible edge case will come up.
No comments:
Post a Comment