OK: a summary for those who're following the story. I was able to VPN into the OP's setup to get hold of the objects as they come along, so to speak. (Which helped tremendously in trying to see what was going on). The situation is this:
When you're setting the attribute of a WMI object (via COM) you employ the usual Python __setattr__ magic, courtesy of the pywin32 COM wrappers, and then you usually call the .Put_ method of the object in question to ensure that changes are written back to the real object for which WMI is proxying. This is what the wmi module's __setattr__ logic does, modulo a certain amount of cacheing of the property object itself which is irrelevant here. Occasionally you create WMI objects from scratch, via the underlying .SpawnInstance_ method which is wrapped in the wmi module by the .new method of the _wmi_class. When this happens, you don't want to call the .Put_ method because there isn't usually an underlying object to write back to: this is a structure, such as ProcessStartup or a security structure, which will be passed into, eg, the .Create method of a Win32_Process object. Therefore, the __setattr__ logic checks that the object whose attributes are being updated has a non-empty .Path_ attribute, which would indicate that it is proxying a real, underlying object. If .Path_ is empty, .Put_ is not called. So far, so good. In the OP's case, one of the complex of objects which arise as you're trying to set up a VM was a sort of template of defaults which somehow has a real, underlying object (and therefore a non-empty Path_) but whose underlying object cannot be written back to. The __setattr__ code was seeing the non-empty Path_ and trying to write back. At which point the code was failing. At the moment, the only workaround I can offer is, for that particular set of updates, to write directly to the underlying COM object, exposed for all wmi module objects as the .ole_object attribute. This bypasses the wmi module's __setattr__ logic and the fault .Put_ call. It's not brilliant, but it's not a great overhead, either. As a long-term fix, I'm not quite sure what to offer: there doesn't seem to be any Qualifier which would indicate whether or not an object is read-only. In principle, a WMI Property can include a "write" qualifier but that only indicates that the WMI property can be written (which, in this case, it can) rather than that the underlying object can have its properties updated. I'll try to find an object with similar behaviour closer to home which might help to narrow down the identifiable characteristics. An alternative (which would apply fairly neatly in this case) is to extend the .set method, which is designed to allow slightly neater updates of multiple attributes, to have an additional flag indicating whether or not .Put_ was to be called. TJG _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
