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:
No comments:
Post a Comment