Las Data Streams del NTFS

Alguno de ustedes recuerda aquellos tiempos de database donde una base de datos estaba guardada en varios archivos?, donde una tabla era un archivo DBF, los indices simples un archivo NDX, los compuestos un CDX y asi? en fin, recuerdan aquellos tiempos donde un programa usaba varios archivos para un dato en especifico y cuando movias ese archivo tenias que mover todos esos datos? Si, ya se que muchos no lo recuerdan y en este momento vivimos en el mundo de los zipfiles o mejor dicho, de los formatos de archivo containers como el ODF de OpenOffice 2 o el OpenXML de Microsoft Office, yep, archivos que en realidad son containers de otros archivitos.

Bien, el problema de contener archivos con otros se resolvio hace mucho tiempo antes con la idea de «adornar» archivos, mas que todo no de «contener» sino de proveer información extra sobre el archivo. Ponganse a pensar, en un principio solo nos interesaban pocos datos de un archivo en si, luego ya necesitabamos muchos mas datos de ese archivo. La idea genero el concepto de atributos y forks de archivo.

El «adornar» archivos con otra data se ve en su mayoria con el concepto de atributos de archivo, en el caso de DOS/Windows vemos el proceso con la metadata existente en archivos comunes como las notas de archivo y similares. En Linux vemos el concepto cuando hablamos de ACLs en sistemas de archivo como XFS, Ext3 (segunda generacion) y ReiserFS. Los atributos son tags cortas, información limitada que acompaña siempre a un archivo. Podriamos guardar todo un archivo en un atributo y asi tener dos archivos en un mismo archivo? la respuesta corta es NO. Como mencioné antes los atributos son cortos, tan cortos que solo un par de lineas de info lo acompañarian.

El problema fue resuelto en los tiempos de la Macintosh, cuando comenzaron las interfaces gráficas. Los ingenieros necesitaban guardar junto con el archivo cosas como icono, info sobre quien lo ejecuta y notas de ejecución del archivo, fue así como nacio el adornar archivos no solo con tags pequeñas, sino tambien con otros archivos. A esto se le llamo File Forks.

En el caso de Windows NT, se necesito implementar los file forks de alguna manera, asi que nacio el concepto de las Data Streams en NTFS. Ambos conceptos son muy similares sino identicos. En teoria puedo meter tanta data como el tamaño del archivo a quien acompaño. Si muevo el archivo movere también su data (entre volumenes ntfs claro esta) y en un concepto bien general una data stream no es un archivo en si, no puede vivir si no existe su archivo a quien adorna. Veamos un ejemplo sencillo.

Desde el Prompt CMD hagamos un archivo sencillo de texto usando notepad:

c:> notepad test.txt

Ahora escribamos algo sencillo en el archivo, que tal el tipico «hola mundo»?

Bien, ahora usemos type para ver el contenido de nuestro archivo

c:> type test.txt

Aparecerá nuestro mensaje. Bien, ahora creemos una stream llamada «adios»

c:> notepad test.txt:adios

Nos aparece un documento en blanco en el cual escribiremos «adios amigo»

bien, salvemos y veamos que nos dice el listado de directorio, puff, solo existe el archivo test.txt, que paso con nuestro test.txt:adios? bien, tratemos de abrirlo usando type tambien. Rayos! no aparece! de plano no existe! bien usemos ahora notepad nuevamente, Vaya! ahi esta nuestro mensaje «adios amigo». Una forma de ahorrarse el uso de type para ver nuestro archivito es con el comando:

c:>more < test.txt:adios

Bien, creemos un directorio llamado test y ahi movamos nuestro archivito test.txt, si volvemos a revisar nuestra stream de datos se movio junto con nuestro archivito. Aunque no lo voy a probar en este momento, si borramos nuestro archivo tambien borramos nuestra stream de datos. Como un directorio es un archivo mas en NTFS, tambien podemos agregarle data streams a directorios.

Porque funciona notepad y no type para mirar nuestra cadena? simple, type usa un approach de busqueda directa sobre el sistema de archivos para encontrar el archivo, y como realmente no encuentra un archivo llamado test.txt:adios (realmente el nombre de la stream de datos es test.txt:$ADIOS) nos falla, Notepad hace una llamada directa al sistema operativo lo que le evita tener que ir a buscar si existe o no el archivo, y como el sistema operativo si sabe lo que es una stream lo devuelve.

Como usamos streams desde nuestros programas de C++ o .Net? simplemente usando los servicios adjuntos que nos ofrecen librerias como windows.h en el caso de C++ o System.IO en el caso de .Net

Ojo, las streams no funcionan en FAT, tampoco asuman que si envian un archivo por correo se va a enviar su stream tambien, asi no funcionan las cosas. Si le agregamos una stream a un ejecutable al ejecutar el ejecutable (vala la redundancia o rebusnancia! :P) no se ejecutara la data stream, tendriamos que ejecutar la data stream directamente. Otro caso interesante es que si tenemos un ejecutable llamado test.exe y una data stream ejecutable asociada a el llamada test.exe:akiestoy y directamente ejecutamos su data stream en el task manager solo aparecera test.exe, y no test.exe:akiestoy. Tomen esto en consideracion.

Algunos dicen que las data streams son un problema en seguridad, yo digo que son igual de seguras que tener una computadora con floppies o puertos usb libres para que lleven ahi sus archivos.

Para terminar el unico programa que conozco para revisar data streams es Stream de Sysinternals, lo pueden bajar aqui http://www.microsoft.com/technet/sysinternals/File… y jugar con streams en su ordenador 😛

Les dejo con el link de wikipedia sobre streams y file forks: http://en.wikipedia.org/wiki/Alternate_Data_Stream…