Tuesday, November 27, 2007 10:11 AMIf I've understood this correctly, there's a maximum URL (as opposed to QueryString) length of 255 (or 260?) chars for SharePoint. How exactly does that affect opening a nested-folder-document in say Word or Excel? And is the limit also there for the explorer view? 255 chars isn't a whole lot for a directory and filename structure, so if it also affects the explorer view; is there a way around it?
Just now I tried creating a dummy structure in a some subsite document library. When my entire QueryString reached 800-1000 chars, it seems the entire SharePoint site managed to crash. Any ideas on why that happens?
Wednesday, November 28, 2007 9:43 AMHi einaros,
SharePoint limits URL length because all relative URL links are stored in the clear forms on the SharePoint content DB and offen this links are used as primary keys to link one table with another. Fields which are used to store these links (for instance tp_DirName from the AllUserData table) allow to store only 256 characters.
Also SharePoint has the limitation of Leaf Name length (it's for instance DocLib name, file name and etc) because tp_LeafName field from AllUserData table could store only 128 characters.
I don't know why SharePoint limits these lengths but it's restricted on the database level.
Therefore you could not create anything with URL that's longer than 255 characters.
May be I'm wrong and I hope that anybody could explain it more accurate.
Wednesday, November 28, 2007 10:36 AMWouldn't these database field limits also affect the maximum number of nested directories in a document library -- even disregarding an url length limit as such?
It strikes me as odd that a limit such as 256 chars is introduced "in this day and age".
I'd really appreciate a deep dive into this, as well as common workarounds (if any).
Wednesday, November 28, 2007 10:54 AMNo, maximum number of subfolders is not affected by these limitation. You could find info about all "count&size" limitations here:
According to the database structure folder from the document library is like "item" but with another ContentType. So you could create any (< 2 millions) items count BUT for the optimum performance item (and I think folder) count on the one level should be < 2000.
Another Microsoft doc (http://technet2.microsoft.com/Office/en-us/library/6f03049f-5bfe-4807-b609-0e2d4a9ec3b51033.mspx) says that "The maximum number of items supported in a list with recursive folders is 5 million items"
What is about workaround? What do you need?
Wednesday, November 28, 2007 11:52 AMWell the problem, as mentioned in the inital post, is that the document libraries do not accept paths exceeding 260 chars. If you create a doclib with a series of nested directories, it'll eventually throw an error at you such as
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.
This also affects opening documents in e.g. word, as well as browsing with Explorer View.
Wednesday, November 28, 2007 12:28 PMhmm, I think that you need to cut your doclib subfolder names. I don't see another workaround.
Wednesday, November 28, 2007 12:52 PMThat's the part that seems odd to me. 260 chars is just ridiculously low for a document library with a hierarchy.
Wednesday, November 28, 2007 1:00 PMAgree. But it's fact
Wednesday, November 28, 2007 1:03 PMI think I'll have to keep bumping this thread until someone from the SP team can make a comment on the matter.
Saturday, March 08, 2008 10:45 PMI think that wouldbe good Idea to do but I don't think that Microsoft Product Team does care about such things they would say that willbe fixed in next release of SharePoint.
Or if somebody is kind enough will say that willbe fixed in Next Service Pack.
Wednesday, March 26, 2008 8:21 PM
When your folder url is formatted to read in this form :
instead of in this form :
then check the string length and observe the following limitations:
http://support.microsoft.com/kb/923906 explains the problem.
In IE6 the limit for a folder path is 100 characters, in IE7 – the limit is 260.
This is the limit for the non url-encoded string, in the shorter 'prettier' format. Otherwise this can confound you if you are counting url characters and trying to figure the breaking length. :-)
Also, although the length is claimed to be 260 characters, when trying to use the document library 'send to' functionality, or creating a new SharePoint link, the url input text boxes do not accept more than 255 characters, so one would do wisely to keep them shorter than 256 characters.
Friday, October 03, 2008 4:40 PMHi there,
Microsoft has published a hotfix for fixing lenght of the URL limitation
Thursday, June 04, 2009 11:25 PMHi MuzaffarA,
I don't see anything about URL limitation on that Hotfix description.
I'm having tha same issue. I have a MOSS farm where our team has deployed an automated solution that uploads documents and creates document libraries that could me nested in several levels. We're having the HUGE problem that those documents cannot be searched nor found via search site.
I've seen a couple workarounds for this on the web related to create an alternate virtual directory on IIS that could redirect to the full-very-long URL (http://fmuntean.wordpress.com/2008/05/12/tiny-url-in-sharepoint/) but as far as I understand this article implies creating a virtual directory for each and every document uploaded and that is just imposible.
Any idea? I think the redirection thing is a good concept but I'm thinking how to apply that to hundred of documents automatically uploaded on a daily basis.
Tuesday, November 03, 2009 1:38 PMHi
Is the url Limitation issue has been fixed in MOSS 2007.
Wednesday, November 11, 2009 9:47 AM
As of now No.
Wednesday, March 10, 2010 4:03 PMGive me a break. Why microsoft product team is not working on this basic issue.
If some one is migrating there file structure this is one the biggest stumbling block.
Wednesday, July 14, 2010 4:29 PM
IMHO there is nothing wrong here that needs fixing!
The reality is this is a web application/site; its not file store and I think should never be treated as such. Your users need to learn to use filters and create Views to differentiate items in the List, not folders. I really wish that Microsoft had never introduced the folder metaphor (after all its not a real folder, its just a View) or the Explore View with drag and drop into SPS 2003 or kept it in later versions - ho hum! :-(
So to repeat; this is not file store and should not be used like it is, as it limits its usefulness as a collaboration tool. So I wouldn't hold your breath waiting for Microsoft to 'fix' it.
Friday, January 14, 2011 10:45 AMYou are correct GarrathE. The problem is that users are creating folders inside of SharePoint.. a hold back from the days when they stored their files in a File System and organized with folders. The solution is to train users properly.
Monday, June 18, 2012 5:49 PM
One note here not mentioned directly in this thread (I did not read all the URL links) is that when a user checks out a docuemnt to edit it, the default location will be a folder of the same path structure. And don't forget the URL is also part of that path...look at your Window dir for your SharePoint Drafts folder for example.
NTFS has a limit on file system length of (not 100% sure) right about that same 256 / 260 size.
I have seen this "bite" users when trying to have long folder names and long file names and then attempting to save that structure as a template. The folder structure which had to also include some temp chars for SharePoint use, exceeded the 256/260 length and the template save failed.
There is a fairly simple SharePoint given workaround.
There are 2 names used by SharePoint - the File Name (what is stored in the DB and on Disk) and the Friendly Name / Display Name.
The first entry should be as short and compact as possible, this is where this thread detail matters...
The second name - the user friendly display name, can be of any length and structure desired, as this is not what is stored / used by the disk system.
So something like a document or folder by the desired name of "Architecuture Recommendations for SharePoint 2010 Production" will be fine for the Display name, but should be stored as "2010Arch" or some such similarly short name.
Likewise you can manipulate a folder by naming a folder such as "Current Architecture Recommendations" to "Arch" and then edit the properties of the folder to change the Title and Description to something much longer.
SharePoint will "store" the original name given at the time of folder creation and use this "internally" but will gladly display any string to the user.
Hope that makes some sense and helps you out...
Thanks, Eric S. Pcubed
Monday, October 22, 2012 10:22 PMIs it still 256 in SP 2010?