More on invalid file and folder names

I’ve been talking about file name limitations for SharePoint 2010 resources a couple of months ago, focusing on illegal characters and path/url length.

There is, indeed, something more which is related to invalid “patterns”.

Just to give you an example, you cannot use folder names that end with:

  • .files
  • _files
  • -Dateien
  • _fichiers
  • _bestanden
  • _file
  • _archivos
  • -filer
  • _tiedostot
  • _pliki
  • _soubory
  • _elemei
  • _ficheiros
  • _arquivos
  • _dosyalar
  • _datoteke
  • _fitxers
  • _failid
  • _fails
  • _bylos
  • _fajlovi
  • _fitxategiak

Take a look at this post by Jeremy Jameson for further information.

The reason for this behavior is the special handling of the so-called “thicket folders”.

What is a thicket folder?

I’m copying here some glossary terms from MS-GLOS:

thicket: A complex HTML document may be stored as a thicket, which consists of the thicket main file along with a hidden thicket folder containing a thicket manifest and a set of thicket supporting files that together store the referenced content of the document (for example, a Web page or Office Word HTML document that includes graphics, pictures, or other media is a thicket).

thicket folder: A hidden folder containing a thicket manifest and a set of thicket supporting files that together store the referenced content of a complex HTML document (for example, a Web page or Microsoft Word HTML document that includes graphics, pictures, or other media). A thicket folder has a name based on the name of the thicket main file, with a suffix added that is recognized as a thicket folder.

thicket main file: The main file of an HTML document that references contained elements such as graphics, pictures, or other media stored as thicket supporting files in a thicket folder.

thicket manifest: An XML file containing a manifest for the set of thicket supporting files that together store the referenced content of a thicket main file, which by convention is named filelist.xml and is contained in a hidden thicket folder.

thicket supporting file: A file containing a graphic element, a picture, or other media that is referenced by a thicket main file and stored in a thicket folder as part of a thicket.

What is somehow surprising is that SharePoint does not prevent you from creating such a folder. I mean, no error whatsoever. It just renames the offending folder with a trailing underscore!

Why? Maybe just to make OOTB migration easier (automatic rename instead of manual renames beforehand).

Anyway… tricky, isn’t it?

Destinazione Office 365

Destinazione Office 365 (which, as you may argue, is the Italian name for Destination Office 365 :-)) is a new technical event organized by Green Team, together with Microsoft, AvePoint and Nintex. The event, which is free BTW, will take place in Microsoft auditoriums in Milan and Rome.

We have defined an initial schedule with two dates.

  • Milan, February 8, 2012
  • Rome, February 14, 2012

Igor Macori, Riccardo Celesti and myself will be talking about Office 365 from the different perspective of End Users, It Professionals, Site Builder and Developers.

You can find detailed information on the event web site, starting from the agenda:

  • 09:30: Welcome (Microsoft)
  • 09:45: Office 365 Overview (Igor)
  • 10:00: Administering Office 365 (Igor)
  • 11:00: Migrating to Office 365 with AvePoint DocAve
  • 11:30: Customizing SharePoint Online (me and Riccardo)
  • 12:30: Automate Office 365 workflows with Nintex Live

And… there’s something more, which I’ll be talking about in a future post.

Stay tuned, and see you there!!

SharePoint Management Shell vs standard PowerShell console

You know that most of the administrative tasks you perform on a SharePoint Farm can be accomplished using PowerShell scripting. You get a bunch of commandlets (more than 600 indeed!) that are registered through the Microsoft.SharePoint.PowerShell snapin, and you can even add your own commandlets using standard SharePoint deployment techiques.

That’s why sometime you just end up firing the default PowerShell console and typing

Add-PSSnapIn Microsoft.SharePoint.PowerShell

Well… you get something that is “similar” to the SharePoint Management Shell Smile

The SharePoint Management Shell is nothing more than a standard PowerShell console (powershell.exe) where tha snapin is automatically loaded upon startup, leveraging a startup script:

C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe  -NoExit  ” & ‘ C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\POWERSHELL\Registration\\sharepoint.ps1 ‘ “

The sharepoint.ps1 script is just a few lines of code:

$ver = $host | select version
if ($ver.Version.Major -gt 1)  {$Host.Runspace.ThreadOptions = “ReuseThread”}
Add-PsSnapin Microsoft.SharePoint.PowerShell
Set-location $home

In the above snippet you can notice the automatic loading of the SharePoint snapin and a “change directory” instruction that brings you to your default home directory (tipically, c:\users\yourusername).

But there’s an additional line:

if ($ver.Version.Major -gt 1) {$Host.Runspace.ThreadOptions = “ReuseThread”}

This line sets the PSThreadOptions of the PowerShell runspace to ReuseThread, which means that the same thread is used for all command line invocations since the shell has started.

The other options are (see

  • Default
    On the local computer,
    UseNewThread is used for runspaces and ReuseThread is used for runspace pools. Server settings are used for remote runspaces and runspace pools. This field is introduced in Windows PowerShell 2.0.
  • ReuseThread
    Creates a new thread for the first invocation and then re-uses that thread in subsequent invocations. This field is introduced in Windows PowerShell 2.0.
  • UseCurrentThread
    Execution occurs on the thread that called the Invoke method. This option is not valid for asynchronous calls. This field is introduced in Windows PowerShell 2.0.
  • UseNewThread
    Creates a new thread for each invocation. This field is introduced in Windows PowerShell 2.0.

If you want a proof of this behavior, just run both a standard powershell console and a SharePoint Management Shell, then run the followind command a few times in each shell.


This instruction prints the internal identifier of the managed thread (i.e. the CLR Thread object)

You’ll notice that you get the same value in the SharePoint Management Shell, whereas you get different values in the standard one. By the way, PowerShell ISE uses the ReuseThread option too.

What’s the issue with the default value, i.e. having a new thread spawn (or picked up from a pool) for every command invocation?

Well… first of all there are some SharePoint objects that are not completely thread safe, sou you should pay careful attention when using them from different threads (even if, in this particular case, you have multiple threads that are not executed in parallel Smile)

Another noticeable issue you may experience, though, is resource leakage: if you create SharePoint objects in one thread and suddenly have no reference to that thread any longer, you end up wasting resources that are not disposed correctly.

Wrapping it up… the SharePoint Management Shell is nothing special, but it’s a little bit more than adding a snap in!!