SharePoint… smart enough to adapt but too dumb to tell you

We came across something recently that is sort of interesting and extremely annoying.

So it seems that when adding a new sub folder to a SharePoint Document library (either through the UI or code), if the folder name ends in “_file”, “_files”, “.file”, or “.files” then SharePoint will automatically tack on an “_” (underscore) to the end of the folder name.  I guess internally they use those patterns in names for something, just like prefixing a folder name with “_” is supposed to hide it so it seems.  Anyway, so they tack on the underscore to prevent it matching the controlled pattern they use… that’s the interesting bit, but its been that way for a long time.

Normally a user might not even notice or care when looking in the UI since it might blend in, but we have a very clever data deployment system, that will create folders on the fly to match the XML data structure we give it for publishing documents and such.  This works great as we get the root SPFolder and drill down the folder path creating sub folders as we go.  The code then returns the folder path as it created it to give us a nice normalized string, and finally we add a document with that final folder path.  In the code, to be on the safe side, we rebuild the folder path to adapt to any changes SharePoint might have made when calling spFolder.SubFolders.Add(folderName).  We simply take the Names of the newly created SPFolder objects and join them together as we create the path… seemed like a sound plan.

This is where it SharePoint screwed us up recently, when testing some customer document loading.  If a name like “TEST_file” is passed in SharePoint will create the folder, appending the additional “_”, but will then return a new SPFolder object with the original name we asked for, and not the new name it actually created it with.  So basically it did one thing, then told us it did another.  The path was created, but we never new of the change and when uploading the document with a URL based on what SharePoint told us it did, the adding of the document failed, complaining the path didn’t exist.

Just a nice example of even when you try to adapt to what an external component (SharePoint in this case) might do, you still can’t trust it, cause it can in essence “lie” :).  This is why testing with real world data is so important, because even if you write a few lines of code, the things you depend on might have millions of lines and as hard as people try, things can be missed, mistakes made, and you might just be the first person out of thousands of other developers to notice because of one little word in all that data.

Advertisement