Using Alternate Data Streams (forks) in Windows 7?

Question

An existing (webbased) project that I work on uses client data and saves reports using the name of the client as file name. Unfortunately, it never filtered this client name so someone entered client names containing a colon (e.g. "workshop:alex") for testing purposes. This results in the filename workshop:alex.pdf which happens to be quite valid on NTFS systems. (Because it creates a file named "workshop" that contains an alternate data stream called "alex.pdf". Since the application also stored the filenames, it had no problems with reading them again, since it just referred to the same ADS. Thus, no one noticed this problem...
However, I recently started to work on this project and it has to be migrated to Windows 7 64-bits with IIS 7. And suddenly, the site did not work anymore with these ADS files! It didn't take me long to find the cause and to realise why it never failed in the past. (and I also cursed the previous developers who never checked this!) But now I wonder why it fails on Windows 7... So, does anyone know?


I have a fix, btw! The filename is now filtered, which solves the problem. I'm just curious about the why. What could cause these problems on the newer Windows versions?


About the application: it is a mixture of a local IIS installation combined with a WIN32 client application. Basically, a reporting solution was developed as a web application and a desktop application was created that previously used Word for reporting purposes. Some manager decided it might be a good idea if the desktop application would use the logic of the web application to generate reports instead. And I admit: it wasn't a very bright idea...
The result is that every user will have IIS running on their system with the web application in it while they also have the desktop application on the same machine. To make them communicate, a separate web service was created with C# while the web application was build in classic ASP and the desktop application in Delphi. The Desktop application will send data through the local web service to the database, then log in into the local web application to tell it to generate the report which it will then download...
Where things go wrong in this Coding Hell isn't very clear. But because the file name is based on data from the desktop application, which sometimes contains a colon, it sometimes will create an ADS instead of a regular file name. On Windows versions before Windows 7, this just seemed to work correctly. The files were written and IIS would also serve them to the desktop application as PDF files. (And from there you could "save as" using a normal filename.
This application just breaks on Windows 7 (64-bits) because it can write the files to the ADS stream, when a colon is added to the data, yet it's unable to retrieve them again. While we now filter out the colons from the generated filenames, I just would like to know the possible causes for this problem. So it's a question out of curiosity...

Answer 1

Hard to say with no error information. You probably checked it already out, but :

• Any chance you're saving the files to a FAT volume ?
• Maybe the antivirus kicking in and treating ADS as attacks ?

Nevertheless, I'm quite curious about this problem now. If you get an anwser to this, please share :)

---

edit : you may not have the time, but this is what I would do :

1. Try to run IIS as administrator and see if you still have the problem
2. If yes, then this maybe an IIS7 issue, or Scripting.FileSystem issue on Win 7
3. If not, then you're now sure that this is security related. Revert IIS to non administrator
4. Give total control to the IIS user for the output folder (where you create/read ADS)
5. This should normally work. Test that nevertheless
6. Remove permissions on the folder one by one and see when you can reproduce your problem again.

My guess would be maybe permissions "READ ATTRIBUTES" or "READ EXTENDED ATTRIBUTES"

If you still got no answer, why not fire up a Sysinternal Process Monitor to check what's really going on. Their tool "Streams" might help too.

• Process monitor : http://www.microsoft.com/france/technet/sysinternals/ProcessesAndThreads/processmonitor.mspx
• Streams : http://www.microsoft.com/france/technet/sysinternals/FileAndDisk/Streams.mspx

Answer 2

Generally network shares do not support alternate data streams as the spec doesn't support them, so if by "migrated" the site and resultant files were copied, then all the ADS streams were lost.

I'd suggest downloading the technet sysinternals tools to verify that the files do in fact have ADS streams on the new server. http://technet.microsoft.com/en-us/sysinternals/bb545046

Answer 3

Do you happen to be reading the name workshop.pdf:alex.pdf instead of workshop:alex.pdf? I don't know how your program works, but does it by any chance try to auto-add an extension, and so fail to find the file (since it doesn't exist)?

Answer 4

I'm not sure if this applies to programming as well (I assume so), but Windows 7 filters out the colons in a filename when trying to access an ADS via the command line, like you were saying; if you put quotes around your filename when attempting to access the ADS you shouldn't encounter this problem. Using quotes around the filename should also work on older OS's as well, so you shouldn't need to worry about compatibility issues across clients.

CMD Example: c:> start "Textfile.txt:cmd.exe"

I imagine the reason for this is not only because of the reason you provided, but also because of something similar to the regular expressions/wildcard issue that has caused me such a hard time while using Linux command lines (* or .*). Something was probably added to the command line that utilizes the colon in the filename or syntax, thus requiring users to distinguish between the ADS and that added command function by escaping the sequence with quotes.