I'm experiencing a weird error while trying to update the author and editor on some files in a site, but not all, and the behavior is strange and inconsistent.
SPListItem item; int newID; item[SPBuiltInFieldId.Author] = newID; item[SPBuiltInFieldId.Editor] = newID; item.UpdateOverwriteVersion();
I've also tried variations of using
item.SystemUpdate(false), etc. from different articles I've found online but no dice. The "User cannot be found" errors still occur. The users do exist and the metadata is updated on some folders using the same users.
This is working as expected on all folders in the document library without a hitch. It also works on about 2/3 of the files in the library. However the remaining number of files result in an exception stating "User cannot be found". The strange thing about this is that it appears to be throwing this error for specific users consistently, but those users also created/edited folders in the library which are updated successfully.
A user is the author and editor of a document and also the folder that the document is in. The folder's author and editor properties and the file's author and editor properties are all updated successfully.
A user is the author and editor of a document and also the folder that the document is in. The folder's author and editor properties are updated successfully, but the file's SPListItem throws a "User cannot be found" exception while trying to update the item.
What is wrong with this? Or how can I approach this in another way that will not result in these errors?
Now here's an interesting turn of events.
After running the above code, for the successes, the user in the UI is updated, however the object model is giving me different results for the users from different methods.
SPFile file = web.GetFile(url); file.Author <-- old author, from: file.Properties["vti_author"] <-- old author file.Item["Author"] <-- new author file.Item["vti_author"] <-- System.ArgumentException
Which means none of the files are actually being updated all the way correctly... Haven't tested the folders yet.
I found out the root of the error, though it doesn't quite make sense to me why this would be an issue while setting the value...
The problematic users are stored in
SPFile.Properties["vti_author"] as being classic auth users missing the claims prefix, though via the UI if you click the link it takes you to the user information page of the proper claims user associated with that same user account.
This leads me to believe this is an environment specific issue either with a remnant of the prior 2007->2010 migration or the classic->claims move shortly thereafter. Fun.