I recently ran into an issue with an error upgrading a standard SharePoint solution file. The deployment operation of the "upgradesolution" call kept returning the following exception:
Some of the files failed to copy during deployment of the solution. [MACHINE NAME] : [WEB APPLICATION NAME] : Error: The copying of this file failed: [FILENAME]. I/O error occurred.
The [FILENAME] above was a specific file in my WSP deployment package. The same error showed up consistently on all of the WFE servers in the farm.
After some initial searching, I found this post, which points to conflicts with a virus scanner as a possible explanation, but in my case, that turned out not to be the issue.
In doing some deeper analysis, I realized that the files on which the solution deployment was failing were primarily image files, and I was reminded that I had moved some updated image files to the farm without going through the solution release process. There were only a few image and CSS files to update, so I had quickly checked them out of our source control system and copied them to the necessary WFE servers. Of course this meant that the read-only flag on those image files stayed in place when I moved them to the WFE servers. And — surprise! — those were the files giving the error the next time that I tried to upgrade the solution containing the same files.
Some things seem obvious in retrospect. The file copy operations of the SharePoint solution framework were raising an exception when trying to overwrite a read-only file. It would have helped me personally if the exception had actually said that — but I’ll take the lump on this one; I guess "I/O error" is close enough. 🙂
There were a couple of takeaways for me:
- This was a good reminder that regardless of the simplicity of the release (e.g. even if it’s only an image or CSS file change, for example) it’s definitely a best practice to wrap up your changes to SharePoint in solution files and deploy them that way. This was a, uh, friendly reminder for me in that regard.
- Less obvious, I had not noticed before that the solution-building process must clear the read-only flags on files somewhere. I haven’t dug in to see, but my guess is that the makecab.exe call must do this? Or perhaps it’s the solution deployment itself? In any case, I routinely have files from source control that are read-only on my system where the WSP file is built, but that are not read-only when I deploy that WSP to a SharePoint farm.
Hope this saves someone some trouble.
