Allowable filename characters in VSS vs. Team Foundation Source Control

I was asked today to compare the list of allowed and disallowed characters in VSS to that of Team Foundation Source Control (TFSC).  The short and simple answer is that anything that's a valid Windows filename character should be allowed in TFSC - so there are less limitations in Team System than in VSS. 

Of course, there are some exceptions and "gotchas" to be aware of:

  • The "$" character may not be used as the first character in an item name ("item" being a file or a folder), but it may be used elsewhere in the filename.  This character is reserved in TFSC to denote the root folder of the source code repository.

  • You can have leading spaces on item names, but not trailing spaces.  To specify an item name with a leading space on the command line, wrap it in double quotes. 

  • You can refer to long filenames using just their 8.3 format short names.

  • In Beta2, if you specify an item name on the cmd line that starts with a "-" character, our command line parser thinks you are supplying a command option (e.g. -server).  Unfortunately, wrapping the item name in double quotes doesn't help in Beta2, but this will be fixed.  A workaround is to specify the item as relative to the current folder.  For example:  .\-foo.txt

  • Similarly, if you specify an item name that as a semicolon (;) character in the name, the command line parser thinks any characters after the semicolon are a version specifier - even if you wrap in double quotes.  Again, this should be fixed before the final release.

  • And one gotcha...  I've verified the Windows command console has the exact same behavior, so this one may stand (the jury is still out, let me know if you have a strong opinion).  If you specify an item name containing the caret (^) character, for example a^b.txt, and you do not wrap it in quotes, the system will ignore the caret and treat the item name as "ab.txt".  This could be dangerous if you already have a file called "ab.txt" - the command would be applied to that file instead of the one with the caret in the name.  The workaround is to specify the item name wrapped in double quotes.  This is the exact behavior exhibited by the "dir" command in the Windows command console.

All of these things will be documented in a page similar to the VSS version above by the time we release.

On a slightly related topic, we respect casing the same way Windows does:  case insensitive lookup with case preserving storage.  So you can check in a file called "ABC.txt" and then check it out by specifying "abc.txt" or "aBc.tXt".  So if you have a team member who likes to buck the coding policies and check in filenames with all caps, you can use the rename command to make them "pretty" again.  We have some bugs around this feature in Beta 2, but again...  they'll be fixed by the final release (and hopefully the next public release).

But please, don't take my word for it!  Play around with this for yourself, and by all means - let me know if you find any bugs 😉

Comments (2)

  1. Abhinaba Basu on marking required fields in work items ⊕ and build types ⊕

    Adam Singer on the latest…

  2. Jon of All Trades says:

    The semicolon restriction still exists in TFS 2012.  Very annoying.

Skip to main content