Adam Singer

Veni, vidi, expertus sum- I came, I saw, I tested

[N]TFS and Alternate Data Streams

Perhaps you’ve heard of them. Files in NTFS may have multiple “Alternate Data Streams” (ADS), each with its own contents. It’s an interesting concept, certainly, but one that requires all software written for NTFS to buy into it, which is always risky. For example, lets say we try:

C:\>echo a > foo.txt

C:\>echo b > foo.txt:bar

C:\>type foo.txt
a

C:\>type foo.txt:bar
The filename, directory name, or volume label syntax is incorrect.

Note that type doesn’t know to look for the extra stream. Still, we can see it by running:

C:\>more < foo.txt:bar
b

Now, suppose we want to edit the file. Let’s say we’re a big time DOS fan, and we still like edit:

C:\>edit foo.txt

Let’s change the first line to “a2” and then save and quit. Now, let’s see what happened to our extra data stream:

C:\>more < foo.txt:bar
The system cannot find the file specified.

It’s gone! Suffice it to say, this is less than ideal.

So, you may be wondering, what does this have to do with Visual Studio’s Team Foundation Server Version Control? Well, let’s give it a go:

echo a > file.cs
echo b > file.cs:bar
tf add file.cs
tf checkin /i
tf get file.cs /force
more < file.cs:bar

Looks like the alternate data stream is gone. This is by design- we made the decision early on not to support ADS. One side effect is that if you’ve set metadata information on the “Properties” -> “Summary” page, this data will be lost upon checkin. Note, however, that this is not true for files like Microsoft Word .doc format for which this data is actually a part of the file itself rather than an ADS.