When is SPFile.Properties != to SPFile.Item.Properties in SharePoint?

Question

One of our customers has a problem that we cannot reproduce. We programmatically copy a document's properties to a destination file using SPFile.Properties. However, for some reason the file's properties do not match the meta data specified on the list the file is stored in.

Now, we can probably solve this by copying SPFile.Item.Properties (not tested yet), but I am just wondering under what circumstances SPFile.Properties is unequal to SPFile.Item.Properties.

Update: We have just received an update from our customer. Using SPFile.Item.Properties always returns the up to date information. However, we still would like to understand the original question.

Punctuate

Tried Reflector? The code paths look very different so I don't think you can rely on SPFile.Properties == SPFile.Item.Properties. – Stier

Haven't tried it with reflector yet. I am hoping to find the official 'documented' difference, and people's experience with it, rather than trying to deduct it by reverse engineering the DLLs. (Although I have been there ;-) – Punctuate

Answer 1

There is a slight difference between SPFile.Properties and SPFile.Item fields and the first one is much, much slower to call.

You have most probably seen Microsoft Office document's "properties" window (this one - http://dradisframework.org/images/tutorial/custom_document_properties.png). These are the properties that are read when you access SPFile.Properties. Reading them is slow since there is some code infrastructure that parses the binary DOC file and finds the properties. (takes up to 30 or something milliseconds for every property access) See more here: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfile.properties.aspx

In SharePoint, every item is an SPListItem and its field values (and I don't use the word "properties" on purpose here) are stored in Sharepoint's content database. So, when you access SPFile.Item.Properties, you actually look at the SPListItem to which the file is attached and look at its properties from SharePoint's content database.

What happens behind the scene, when you upload a file having some "Office properties" set, is that SharePoint copies them to same-named fields in SPListItem. (Some information about it here: http://weblogs.asp.net/bsimser/archive/2004/11/22/267846.aspx)

This is why these properties typically have the same value, BUT it only happens if SharePoint knows how to read metadata from your file and write them back. So, in case you put a .txt file in your SharePoint store, you will not get any SPFile.Properties back.

Massenet

I have marked this one as the answer as it is the best description so far (although I have not verified it). Yet it doesn't explain why the properties are not completely in sync. – Punctuate

1. these properties cannot be in sync in case when the file type does not allow it, as this is for .txt, .pdf and other non-office files 2. when you open a document library item for editing in /Forms/EditForm.aspx?id=123, you are editing the SPFile.Item values, not the SPFile.Properties and the ones that can be synchronized are later sycnchronized by SharePoint. – Massenet

Answer 2

The user will always see the ListItem Properties and not the SPFile properties in a document library. So using the ListItem properties in the copy is the way to go.

Midinette

Thanks Koen, is there any evidence of this or is it an educated guess? Still wondering why SPFile.Properties is there at all and doesn't always match. – Punctuate

Answer 3

I believe this issue is related to the Sharepoint property promotion/demotion feature which enables document properties to be embedded in the physical MSOffice file and travel with it to the client etc. This however is only supported currently for Office file types (to my knowledge).

Jonathan

Ereshkigal

Correct, not dissimilar from what @Massenet states in the entry marked as the answer. – Punctuate

Answer 4

Trying to find the "official documented" anything for sharepoint is pretty much undoable. :-D. The online docs suck, you are better of using blog entries etc.

P.S. I agree with Alex here. Although an SPFile never exists in a list without an accompanying SPListItem, the connection between the 2 can get corrupted (i.e. being able to edit the list item but the file is not openable). This to me indicates information about the 2 is stored in different locations in the content db. I have had this happen before.

Ashtray

Thanks, I consider Blog Entries 'Official Documentation'. In case of SharePoint you really take whatever you can get. – Punctuate

+1 for official documentation. :D Also, I would agree with Colin.. there is something going on because of the difference between a SPFile and a SPListItem. – Radke