File name limitations

Based on my experience with customers, training attendees and, more generally, end users, if I ask “What is SharePoint” the answer I get back most of the times is “It’s a document management system”.

Of course it is – also – a document management system. I presume that DM features, being there since the very first version of the product, connotate the product especially for people who do not know it in depth.

That said, and even if you want to consider it just a document repository, it requires you to obey a set of rules for files and, more generally, folder names.

Most of these rules are a consequence of the fact that a file/folder name *is* the file/folder url, and as such you cannot have anythiing in there Smile

Here’s a short list of the limitations you should consider when defining names

Forbidden characters.

You cannot use any of the following characters:

  • /
  • \
  • :
  • *
  • ?
  • <
  • >
  • |
  • #
  • <TAB>
  • {
  • }
  • %
  • ~
  • &

Plus, the last character of the file name should never be a dot (.).

File name length.

The file name (just the name, not the full path) should be less than 128 characters, including the file extension.

Path length.

The full url of the file/folder should be less than 260 characters.

And maybe

Beyond these basic rules, there may be something else that is not strictly required, but could immensely help avoid bugs: for example, you can include a + character in a file name, but you will break any code that does not escape urls correctly (a plus character in urls is translated to <SPACE>). You may argue that this is not your fault, if something breaks because it doesn’t handle escaping correctly. And you are right… but anyway, sometimes it’s just a matter of convenience Smile

Refinement Filter Generator – Show more links

Refinements are a welcome addition to the Search/Query capabilities in the default SharePoint 2010 user interface. I remember that most of our SharePoint 2007 projects that involved some search results customization have been implemented relying on the Faceted Search project (still available on CodePlex) or on some commercial tolls (Ontolica, now Surfray, being one of those).

The way refinement panels work is somewhat complicated, as it entails server components (aka filter generators), server controls (OOTB) as well as some XSLT tricks that you can use to customize the refinement UI.

One of these tricks determines how the “Show More Links” feature is realized.

You need the help of the filter generator in order to discriminate between “visible” links and links that are instead hidden, waiting for an explicit request by the user.

The filter generator returns a bunch of XML markup, where you may have two sections (two elements) that contain either “top results” and “all results” (the threshold is typically defined by a property of the generator instance).

You may end-up with something like this [most of the code has been omitted]:

XmlElement element = filterXml.CreateElement("FilterCategory");

Element.SetAttribute("Id", category.Id);

element.SetAttribute("ShowMoreLink", category.ShowMoreLink);

element.SetAttribute("MoreLinkText", category.MoreLinkText);

element.SetAttribute("LessLinkText", category.LessLinkText);

XmlElement topElements = filterXml.CreateElement("Filters");

XmlElement moreElements = filterXml.CreateElement("MoreFilters");

Of course, most of the hard work is done by the logics of the refinement filter generator.

But… there’s something that is up to you – the site builder – which is of course the presentation of these aggregations.

OOTB, SharePoint 2010 comes with some XSLT that probably fits most of your needs.

But this may not be enough when, for example, you have developed a custom filter generator (or you have downloaded or bought one) and you need to make it available.

The example I’m bringing to your attention, and which of course gives the title to this post, is related to the way the OOTB XSLT renders the “All Results” fragment.

Just take a look and try to find-out what I’m talking about:

<xsl:if test="$ShowMoreLink=’TRUE’">

<xsl:variable name="MoreFilters" select="MoreFilters/Filter" />


<xsl:when test="$FilterCategoryId and ($FilterCategoryId != ”) and ($FilterCategoryType = ‘Microsoft.Office.Server.Search.WebControls.ManagedPropertyFilterGenerator’)">


<xsl:when test="$FilterCategoryId and ($FilterCategoryId != ”) and ($FilterCategoryType = ‘Microsoft.Office.Server.Search.WebControls.TaxonomyFilterGenerator’)">…



Got it?

The OOTB XSLT template applies (and then renders) the “All Results” section differently according to the type (the .NET Type) of the refinement filter generator. In the above snippet, there’s a “choose/when” statement (the equivalent of the “switch/case” or “Select/Case” syntax construct you may be familiar with) that is there exactly for this purpose.

Needless to say that, if you need to render links also for refinement panels based on your custom generator, you also need to update the XSLT transformation accordingly:

<xsl:when test="$FilterCategoryId and ($FilterCategoryId != ”) and ($FilterCategoryType = ‘GreenTeam.SharePoint2010.EnterpriseSearch.MultiValueFilterGenerator, GreenTeam.SharePoint2010.EnterpriseSearch, Version=, Culture=neutral,PublicKeyToken=7b398aba874a4ea9’)">



TreeSize – A useful tool for reporting and statistics about File System Usage

Some days ago a stumbled upon this tool:

A free version is available for download, with limited capabilities.

The commercial version adds more powerful reporting features as well as allows connecting and getting information from a network share.

You can perform several type of analysis, and get back an output in different formats (Excel, Csv, Html, etc…)

I strongly encourage you to give it a try.

I’m using it mainly in two different scenarios.

First and foremost, which may seem obvious, when I need to free some disk space (I always run out of disk space…).

Then, and this is happening more and more frequently, as a way to discover permissions and storage usage on shared drives and folders.

Cool 🙂