Question

Today I have seen this weird magic NTFS system supports: each file can have multiple data streams. Basically one could have a file a.txt of 0b size but there can be any number of bytes hidden in a separate data stream for that file. This is strictly NTFS related magic and I don't see any noble reason for having these streams around. You can look for NTFS streams with the help of the streams utility from Sysinternals. This will show you that basically every one of those nasty thumbs.db files comes with an extra data stream.

Okay, now I have seen this magic work on a Windows NT4 system, streams added to files, copied over, deleted (with the help of the aforementioned utility), but I am now trying this at home on my Win XP system, but although I can detect the existing streams, I can't display their contents, can't create new ones, or very much anything when I use the filename:streamname syntax.

I get this error:

The filename, directory name, or volume label syntax is incorrect.

Example: Output from the streams utility:

c:\DOWNLOADS>streams.exe -s .

Streams v1.56 - Enumerate alternate NTFS data streams
Copyright (C) 1999-2007 Mark Russinovich
Sysinternals - www.sysinternals.com

c:\DOWNLOADS\1013.pdf:
   :Zone.Identifier:$DATA       46

c:\DOWNLOADS>type 1013.pdf:Zone.Identifier
The filename, directory name, or volume label syntax is incorrect.

Why can't I display the contents of the alternate data stream?

Looking at the Microsoft documentation on "How To Use NTFS Alternate Data Streams", I can see that this applies to my operating system, although they do mention that these streams will not be supported in the future. Anyone can shed any light on this?

Was it helpful?

Solution

From the top of my head: NTFS datastreams were introduced in Windows NT 4.0 and have been around in all descendants (excluding the win-95 descendants: 98, Me). In XP, Vista and Win 7 they're still around. As long as Windows versions support NTFS, they will support file streams. They will support NTFS for a long time to come.

The error you have is described on the page you show in your question. The type command doesn't understand streams. Use:

more < 1013.pdf:Zone.Identifier

Working with streams

Microsoft only has a handful commands that work with streams, in fact, only <, > work with streams, and thus only commands can be used that can work with these redirect operators. I wrote a couple of blog posts on alternate datastreams on how you can still manipulate streams with only these commands.

Streams will only work with programs that are designed to work with them, simply because they need to be treated specially (compare junction points, also a feature of NTFS, but the driver hides the details and programs do not need to do anything special: they just consider the junction point a real file).

When you try to open a file stream using start filename:streamname and a program says something like "illegal filename" or "file not found", and you are positive that the stream name is correct, then it's likely that the program does not support streams. I noticed that Notepad, Wordpad and Word/Excel work correctly with streams, though Word and Excel consider the files dangerous. Here are some experiments you may try.


NOTE: you seem to consider alternate data streams odd. They are odd because they are so hidden, but many major file system (HFS, NSS) have it and the concept dates back to the early 80s. In fact, originally the streams were added to NTFS for interoperability with other filesystems.

OTHER TIPS

BTW, you can open AltDataStream with notepad:

notepad.exe 1013.pdf:Zone.Identifier

Also, you may specify type of AltDataStream (not only with Notepad, it is 'full stream name'):

1013.pdf:Zone.Identifier:$DATA

This is strictly NTFS related magic

Not so - Mac OS has had these since back in the day, they are called forks in that world, and you would use ResEdit to get at them. The classic use of them is to bundle media assets along with an executable.

One possible purpose for alternate stream: meta-data. One can add, for a document, a large description without affecting the content of the original file.

The Win32 API handles the naming of alternate streams just fine.

CMD, on the other hand, does some funky parsing of the file name when it's possible to have */? expansion and barfs when a ":" is present. That's why copy and type fail but simple redirection works.

The error literally means that it is not being recognized as an alternate data stream and the reference you're making contains a certain character that is not allowed in a path name (the :; other characters not allowed include \\,/, etc).

Try:

start this_is_a.txt:ads.exe

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top