If 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?

Hi 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.

Wouldn'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).

No, maximum number of subfolders is not affected by these limitation. You could find info about all "count&size" limitations here:http://www.microsoft.com/resources/documentation/wss/2/all/adminguide/en-us/stsb07.mspx?mfr=trueAccording 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?

Well 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.

hmm, I think that you need to cut your doclib subfolder names. I don't see another workaround.

That's the part that seems odd to me. 260 chars is just ridiculously low for a document library with a hierarchy.

Agree. But it's fact

I think I'll have to keep bumping this thread until someone from the SP team can make a comment on the matter.

I 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.

When your folder url is formatted to read in this form : http://server.com/site/subsite/subsubsite/TeamDocuments/foldername instead of in this form : http://server.com/site/subsite/subsubsite/Team%20Documents/Forms/AllItems.aspx?RootFolder=%2fsite%2fsubsite%2fsubsubsite%2fTeam%20Documents%2ffoldername 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 creatinga 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.

Hi there,Microsoft has published a hotfix for fixing lenght of the URL limitationhttp://support.microsoft.com/kb/956056/Thank you,MuzaffarMickey

Hi 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.Regards,Marcel JeanneauMicrosoft Peru

HiIs the url Limitation issue has been fixed in MOSS 2007.Any Idea?Regards-Raj

As of now No.Neeraj Rai

Give 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.

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. Regards, Garrath.

You 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.

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