Files/Folder Names Exceeding 260 URL Length [SPS 2003 to MOSS 2007 Migration]

Issue Background

In SharePoint (V2 and V3) you cannot create or have a file name or a folder name and combination of folder and file name (128 characters max) that cannot exceed 260 characters in length in the final resulting URL. Read following Microsoft KB Article for more details http://support.microsoft.com/kb/894630. So based on this you not be able to upload or create fine file/folder under the SharePoint Portal or WSS that would result with an item that exceeds 260 characters in length.

Now, lets look at the Upgrade scenario for SharePoint 2003 based Portal Site Collection. In V2 Portal the Area address are based on the “bucket web” concepts (Go hear for understanding what SPS 2003 did for Web address https://blogs.msdn.com/danielmcpherson/archive/2005/05/18/419160.aspx). When you upgrade a Portal Site Collection to MOSS 2007, the site collection will be upgraded to the “Collaboration Portal” Site Template. What the Upgrade process does is it removes the “bucket web” address nodes and maps each sub webs with the existing web URLs hierarchically. See below table:

Area Path->Address	MOSS Sub Web Address
Home->/	/
Home: Sub Area 1->/C1/SubArea1	/SubArea1
Home: Sub Area 1: Sub Area 2 ->/C2/SubArea2	/SubArea1/SubArea2
Home: Sub Area 1: Sub Area 2 :Sub Area 3 ->/C3/SubArea3	/SubArea1/SubArea2/SubArea3

For each such webs where the bucket web addresses are changed the Upgrade process will also add a redirector to address the breaking URL. But I will cover this topic with an issue this change introduces in a separate blog. (Refer to http://cregan.wordpress.com/2007/11/16/sharepoint-gradual-upgrade-random-page-error-this-page-is-redirecting/ for more details)

Now what above URL change introduces is the folder and/or documents URLs that were close to exceeding 260 characters in length will start hitting the 260 URL limit threshold as some of the inner sub webs URL is now extended by prefixing with the parent web URL.

If you guessed it, when you upgrade SharePoint 2003 Portal Site Collection (May not apply for WSS 2.0 Site Collection as there are no bucket webs and the URL schema remains same), your Upgrade.Log will report following error:

[PortalSiteUpgradeAreaAndListingData] [12.0.1.0] [INFO] [----date time---]: Trying to move Area "Sub Area 1: Sub Area 2" from "/C2/SubArea2" to "/SubArea1/SubArea2"... [PortalSiteUpgradeAreaAndListingData] [12.0.1.0] [INFO] [-----date time-----]: Could not move web due to the following error, trying to move it to the unmovable web holding area instead. Microsoft.SharePoint.SPException: The specified file or folder name is too long. The URL path for all files and folders must be 260 characters or less (and no more than 128 characters for any single file or folder name in the URL). Please type a shorter file or folder name.

and further you will also see the following error…

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< [PortalSiteUpgradeAreaAndListingData] [12.0.1.0] [INFO] [---date time---]: Instead of moving area to "/SubArea1/SubArea2 ", upgrade has moved the area to "/z/SubArea2 " due to the above error. Please revisit this area and resolve any issue and manually move the area to the correct location. [PortalSiteUpgradeAreaAndListingData] [12.0.1.0] [INFO] [----date time-----]: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

So the Upgrade Job has created a Sub Web called “Unmovable Webs” with the url “/z” under the root and moved the webs that are exceeding URLs. You will also observer the below log message at the beginning of the Upgrade.Log file. So why did Upgrade Job choose “/z”? So as to create shortest Web Path to accommodate webs that had hit the threshold.

[PortalSiteUpgradeAreaAndListingData] [12.0.1.0] [INFO] [---date time----]: Will use "z" as the web name of the unmovable webs holding area.

The Upgrade Job will move the web even if there is a single item that exceeds the 260 character URL limit.

Analysis Approach

You can follow below pointers to plan for addressing your Unmovable Webs:

• Searching: Always plan for performing test upgrades before thinking about doing a production upgrade. After running test upgrades review your Upgrade.log file. Look for each instance of “<<<<<<<<<<<<" to find each of the Webs that has exceeded.
• Target URL: Note each of the Web’s intended destination URL from the Upgrade Log, so that when you have addressed the items that are causing the exception, you can try move back the Web from Unmovable webs to the intended Web Location (You can do this from “Content and Structure” feature of Publishing Site)
• SQL Query: Now you must wondering how am I supposed to know which item(s) is/are causing this exception. Well, you can try derive a SQL script to run against your SharePoint 2003 Content database (<Portalname>_SITE DB). The V2 content DB will tell you as it is in the V2 state before the Upgrade, that given the state, for each documents and folders (which are stored under the “alldocs” table) and by appending the folder path and the document name and calculating the possible end URL length (remember your from your address, the server name or DNS will not count to words the 260 characters limit). Below is a sample SQL Script that you can try against the V2 _SITE DB. (Caution: Large databases and/or documents heavy sites may take more time to run the query. Always first try in the test environment and may be start with Top 10,100, 500 etc filter)

select top 100

SUM(len(dirname)+len(leafname)) as Total,

len(dirname) as DirLength,

dirname,

len(leafname) as LeafLength,

leafname

from alldocs with (NOLOCK)

where DeleteTransactionID = 0x

and IsCurrentVersion= 1

group by dirname, leafname

having cast(SUM(len(dirname)+len(leafname)) as int) > 260

order by total desc

Solution

Once you have the list of items that are causing the exception, you can plan on managing the items. You can try move the items to higher URL name space, rename the document and/or folder names. If you can perform rename/move management before the Upgrade Job is run, potentially you are letting the Web upgrade and be placed under the respective URL hierarchy. If you cannot then let the Upgrade Job complete, then manage the exceeding times and try moving through the Content and Structure screen. The move function will once again check to make sure the web is 260 URL limit safe based on where you are moving. Other wise the move will fail completely, leaving the web under the Unmovable webs location.