This post requires a bit of explanation.  In SharePoint Folders and Files are really special items – well, most of the time, but I’ll get to that in a moment.  Many of the typical kinds of things that you want to do have to be done with the item object – for instance if you want to manage security.  So I was writing a tool the other day that went through and fixed up security a bit.  (Sort of like the Windows NT+ command line utility CACLS.)

Something happened that didn’t initially make any sense.  When I did an SPFolder.Item I would sometimes get null back as the result.  That’s not suppose to happen – or so I thought.  If I have a folder in a document library it has a corresponding item.  If I have a file in that library it has a corresponding item … most of the time.

The problem comes in when there are files which are necessary for the operation of the list or library which are ghosted (or uncustomized, if you prefer).  You see when a library is created the forms for displaying and item, creating a new item, and editing an item are all provisioned too.  The result is that the document library (or list) has a Forms folder and in that forms folder are created at least those three files.

So when you’re happily traversing down through a structure it’s more than possible that you’re going to encounter SPFolder and SPFile objects that have no corresponding SPListItem.  They don’t have one because they’re not an item in the list.  They’re special files and folders added to support the operation of the list.

Of course, that may not stop you from doing a double take when the SPFolder.Item call returns null.