I have a feature that provisions a heap of files including layouts and images into a MOSS site. Over the lifetime of this site we have altered the provisioning file, the Elements manifest, a number of times: adding files, removing files, and changing the file structure in the feature folder. Unfortunately we have discovered that if you remove a file from a provisioning document then reactivate the feature the SPFile of the removed file remains in the content database.
Since these files are ghostable they have a property in the sharepoint content db called 'SetupPath', which is basically the Template folder relative path of the original file. This file is presumably used when the file is in its unghosted state. Since I have changed my feature this setup path refers to a file that doesnt exist.
The ramifications are: I cant update the file in the API any longer, It doesnt appear via the GUI and when I run a content deployment, a full content deployment, I get file not found errors. Worse, given there is a good 1000 of these files that have been removed, there are something like 3.5k errors on every full content deployment. The push doesn't stop, but so many errors are disconcerting and hide any actual catastrophic errors should they occur.
Finally if I update a file, giving it a new path, then when that file is referenced in sharepoint a 404 is thrown. Super bad if the file happens to be a layout (all pages using it fail).
I've coded up code to delete SPFiles that have are no longer provisioned, problem solved. However files that are still being used but just have an incorrect setup path, I am at a lost.
I can go SPFile.Properties["vti_setuppath"] and see the incorrect setup path. However, though I can set this property I cannot seem to make it stick. SPFile.Update() doesnt work, and neither does checking the file in and out.
Any help would be appreciated.