enter image description here

As can be seen from the debug image when I call SystemUpdate(false) of a SPItem, that SPItem's File object's ModifiedBy attribute changes to "SHAREPOINT\system". Sorry, it's a bit weird way to present it :). 'destinationFile' is an SPFile object. And since the object is not the same as the one in the Database after SystemUpdate call, it doesn't change on the debugger.

But why? It does as promised and it doesn't change the item's ModifiedBy etc.. But the SPFile object under it does change.

Anyway, how can I make sure both SPItem.ModifiedBy and SPFile.ModifiedBy don't change after I make some changes on SPItem.Properties?

  • Are you logged on with a site collection administrator account when running the code? Did you try with a non-site collection administrator account? – Bernd Rickenberg Nov 18 '11 at 18:02
  • Sorry for the awfully late reply, I was kind of away. Yes, I have to utilize the administrator account due to several issues. Tried giving the modifier's userToken which raises "Access denied" exception in case the user is a Contributor which is one of the reasons I am impersonating system account. Still, I think ListItem's modifier should be synchronized with SPFile's modifier. – Natan Nov 25 '11 at 14:00

The reason you're seeing this is because of references crossing each other.

You say destinationFile is an SPFile.

You call destinationFile.Item.SystemUpdate(false). Which is fine. You have to watch though, because SPFile.Item returns a reference to an SPListItem. If you call this twice, you get a different reference to the SPListItem. Therefore, if you call that, then try to access SPFile.Item.File You'll actually get a different reference to the SPListItem than you last checked, therefore it appears to the debugger that it's inconsistent.

Try this method (pseudo-coded):

SPFile destinationFile = ... (get the file reference somehow)
SPListItem destinationFileItem = destinationFile.Item;
destinationFileItem["someProperty"] = someValue;
// do some other stuff on the destinationFileItem object
destinationFileItem.SystemUpdate(false); // do not refer back to destinationFileItem after this point
// If you need to refer to the item again, get a new reference to store it in a variable. You can re-use destinationFileItem, though I'd set it to null first.
| improve this answer | |

Hope this link can help you link


| improve this answer | |
  • I am already doing a SystemUpdate(false) if that was the answer from the given link. It does reserve the ListItem's properties, but not the SPFile's which is the issue here. Thanks- – Natan Nov 25 '11 at 13:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.