Wednesday, December 12, 2012

2012-12-12 Wednesday - Windows MAX_PATH?


I love to create organization from chaos.

In my consulting practice, I have a very organized approach to creating a directory structure for each client engagement, and within an engagement - a very organized sub-directory layout so that I can quickly find things long after I've filed them away.

Recently, while trying to help re-organize the logical directory structure of a client's Sharepoint site for a project - I hit a puzzling error message:

[click to view]


Without intending to be too verbose, my relatively few nested directory names exceed a Sharepoint limitation. I had simply provided useful and meaningful directory names - and organized them in such a way as to facilitate quickly finding information.  However, some inherent implementation constraint in the design of Sharepoint results in an arbitrary maximum length constraint for an URL+filename (260 characters) and a further maximum length constraint on a file name (128 characters).

While one can understand a limit for a file name or a directory path in the physical file system - it just seems strange to have an arbitrary restriction on how deeply one can nest a logical 'directory' structure within a content management system.

In doing a quick Google search, I came across the following article that may be of interest to others, as it mentions a MAX_PATH with a default of [260]:
http://msdn.microsoft.com/en-us/library/aa365247.aspx

Maximum Path Length Limitation

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string" where "" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

Seriously Microsoft? You designed an API that exposes a physical constraint of your file system design - and applied it to the web?

I suspect that if Sharepoint were designed with something like the JSR 170 approach (Content Repository API for Java) - then this type of limitation would not be an issue.

Apache Jackrabbit is an implementation of JSR 170


2012-12-16 Sunday Update:

Apparently there is another manifestation of this constraint in the Microsoft ASP.NET implementation:

HttpContext.Current.Server.MapPath fails for long file names

Back in 2006, some empirical findings were published on Boutell.com that are worth noting: http://www.boutell.com/newfaq/misc/urllength.html

...as you will note, 2,000 would appear to be a minimally supported length across the various browsers and servers that were tested.

Per Microsoft Support, IE supports a max. URL length of 2,083
http://support.microsoft.com/kb/208427 
 

 ...so I guess it is just the design and implementation of Sharepoint.

  

2013-03-24 Sunday Update

You will also run into this issue if you are still using xcopy

http://www.terminally-incoherent.com/blog/2007/02/05/xcopy-insufficient-memory/  

 


No comments: