TEMA 3: FICHEROS................................................................................................................

CONCEPTOS BÁSICOS..........................................................................................................................2
RUTAS DE FICHEROS Y DIRECTORIOS....................................................................................................3
SINTAXIS EN WINDOWS........................................................................................................................3
RUTAS INDEPENDIENTES DEL SISTEMA OPERATIVO.....................................................................................4
OPERACIONES CON RUTAS.....................................................................................................................5
REPRESENTACIÓN DE FICHEROS Y DIRECTORIOS EN .NET......................................................................6
ELEMENTOS COMUNES..........................................................................................................................6
ELEMENTOS ESPECÍFICOS DE DIRECTORIOS...............................................................................................9
ELEMENTOS ESPECÍFICOS DE FICHEROS..................................................................................................10
FLUJOS DE ENTRADA-SALIDA.............................................................................................................11
LECTURA Y ESCRITURA.......................................................................................................................12
MOVIMIENTO POR EL FLUJO................................................................................................................12
VOLCADO DE DATOS EN FLUJOS...........................................................................................................14
CIERRE DE FLUJOS.............................................................................................................................14
FLUJOS DE ENTRADA-SALIDA EN FICHEROS..........................................................................................14
CREACIÓN DE OBJETOS FILESTREAM....................................................................................................14
MANIPULACIÓN DEL CONTENIDO DE LOS FICHEROS..................................................................................16
CONTROL DE CONCURRENCIA EN ACCESOS A FICHEROS............................................................................20
ACCESO NATIVO A FICHEROS...............................................................................................................20
FICHERO BINARIOS...........................................................................................................................21
FICHEROS DE TEXTO.........................................................................................................................22
LECTURA DE FICHEROS DE TEXTO.........................................................................................................22
ESCRITURA EN FICHEROS DE TEXTO.....................................................................................................25
MANIPULACIÓN DEL SISTEMA DE ARCHIVOS........................................................................................27
MANIPULACIÓN DE FICHEROS..............................................................................................................27
MANIPULACIÓN DE DIRECTORIOS..........................................................................................................29
MANIPULACIÓN DE RUTAS..................................................................................................................30
DETECCIÓN DE CAMBIOS EN EL SISTEMA DE ARCHIVOS.........................................................................30
SELECCIÓN DE FICHEROS A VIGILAR......................................................................................................31
SELECCIÓN DE CAMBIOS A VIGILAR.......................................................................................................32
DETECCIÓN SÍNCRONA DE CAMBIOS......................................................................................................32
DETECCIÓN ASÍNCRONA DE CAMBIOS....................................................................................................34
EJEMPLO: CIFRADOR DE DIRECTORIOS..................................................................................................35
PROBLEMAS DE DESBORDAMIENTOS DEL BUFFER DE CAMBIOS...................................................................36
FICHEROS TEMPORALES....................................................................................................................37
 Tema 3: Ficheros

Conceptos básicos

Un fichero puede verse como una porción de un dispositivo de almacenamiento no

volátil (disco duro, disquete, etc.) a la que se le asocia un determinado nombre, estando
en principio la cantidad de datos que puede almacenar sólo limitada por la cantidad de
espacio del que disponga en cada momento el dispositivo donde se almacenen esos
datos o por las características del cada sistema operativo. Por no volátil se entiende que
a diferencia de lo que ocurre con otros almacenes de datos como la memoria RAM, la
información en ellos almacenadas no se pierde al apagarse el ordenador.

Dada la importancia de los ficheros como almacenes no volátiles de la información, la

BCL incluye todo un espacio de nombres llamado System.IO especialmente orientado al
trabajo con ellos. En este tema se realizará un estudio en profundidad del mismo y se
explicará cómo se pueden aprovechar los servicios que sus tipos ofrecen para facilitar la
manipulación de los mismos. Por ello, salvo que se indique explícitamente lo contrario
puede considerar que todos los nuevos tipos aquí citados forman parte de dicho espacio.

Aunque cada sistema operativo puede tener su propio formato de nombres de fichero,
nosotros veremos el que se utiliza en la plataforma .NET, que básicamente puede
considerarse que consiste en nombrar a los ficheros usando hasta 259 caracteres
Unicode imprimibles e interpretándose el nombre que se les dé según este formato:
<nombre>.<extensión>

<nombre> indica cuál ha de considerarse que es en realidad el nombre del fichero y en

<extensión> se indica cuál es el tipo de fichero del que se trata. La idea es que ficheros
con el mismo tipo de contenido tengan una extensión común para que así sea más fácil
identificar su contenido, por lo que lo que distinguirá a unos ficheros de un tipo de otros
de su mismo tipo será su <nombre> Así, los ficheros de texto generados por Microsoft
Word tienen extensión doc, las compresiones con Winzip tienen extensión zip, etc.

Los ficheros se agrupan en directorios o carpetas, que pueden verse simplemente

como nombres comunes bajo los que se agrupan conjuntos de ficheros relacionados
entre sí. Cada directorio pueden contener a su vez otros directorios, lo que hace que el
sistema de archivos adquiera una estructura jerárquica donde cada fichero o directorio
tiene como padre al directorio en que está contenido. Obviamente, para que ésta sea una
estructura finita habrá de existir un directorio raíz que contenga a todos los demás y
no esté contenido dentro de ninguno otro.

La utilidad de los directorios es doble:

1. Permiten organizar el sistema de archivos del ordenador de manera que sea más
fácil localizar ficheros en él, pues evitan tener que buscarlos entre todos los ficheros
de la máquina y acotar las búsquedas tan sólo a los incluidos en ciertos directorios.

2. Evitan conflictos de nombres, pues si cada aplicación instala sus ficheros en un

directorio propio podrán coexistir en una misma máquina varios ficheros con el
 mismo nombre siempre y cuando se almacenen en directorios distintos. Como verá,
la relación entre ficheros y directorios es muy similar a la relación que en C# se
establece entre tipos y espacios de nombres.

Como los nombres de ficheros, en .NET los nombres de directorios pueden ser
cualquier combinación de caracteres Unicode imprimibles excepto \. Sin embargo,
ahora el límite de caracteres que pueden tener está limitado a 248 y se ha reservado un
el nombre especial \ para el directorio raíz.

Rutas de ficheros y directorios

Sintaxis en Windows

Como cada fichero y directorio está a su vez contenido dentro de otro directorio, para
identificarlo unívocamente habrá que indicar el camino que lleva desde el directorio raíz
hasta dicho fichero o directorio. Esto se le suele denominar su ruta completa, y en cada
sistema operativo sigue su propia sintaxis. Por ahora nos centraremos en la usada en los
sistemas Windows, aunque luego veremos el diseño de la BCL es bastante flexible y
permite escribir aplicaciones independientes de sistema operativo en este aspecto.

En Windows la sintaxis que sigue para escribir una ruta completa es de la forma:
<nombreDirectorioPadre>\<nombreFicheroODirectorio>

Como cada directorio puede estar contenido dentro de otro directorio, lo que se indica
en <nombreDirectorioPadre> es a su vez la ruta completa del directorio donde se
encuentra el fichero indicado en <nombreFicheroODirectorio>, y obviamente el primer
carácter de cualquier ruta completa será el \ correspondiente al directorio raíz. Por
ejemplo, la ruta completa de un fichero datos1.dat incluido dentro de un directorio
llamado Datos es \Datos\datos.dat, pero si dicho directorio se encontrase a su vez
contenido dentro de Programa entonces sería \Programa\Datos\datos.dat

Si al indicar el nombre de un fichero no se diese su ruta completa se consideraría que la

ruta especificada es una ruta relativa a la posición actual en el árbol de directorios. Es
decir, que se trata de una ruta en la que <nombreDirectorio> ha de considerarse que es el
directorio desde el que se la hace referencia al fichero. Por tanto, si desde el directorio
\Programa se quisiese hacer referencia al fichero datos.dat del ejemplo anterior
bastaría indicar Datos\datos.dat, pero para hacerle referencia desde el directorio
\Programa\Datos bastaría indicar datos.dat.

Adicionalmente a la sintaxis vista, en sistemas operativos como Windows donde se

puede trabajar con múltiples unidades de disco a cada una de las que se les asocia un
nombre diferente, la sintaxis anterior para las rutas completas se ve ampliada así:
<nombreUnidad>:<nombreDirectorio>\<nombreFichero>

Por ejemplo, A:\Programa\Datos\datos.dat haría referencia al fichero datos.dat

del directorio Datos incluido dentro del directorio Programa de la raíz del dispositivo
de nombre A (unidad de disquete de 3.5”), y C:\Programa\Datos\datos.dat se
referiría al fichero datos.dat del directorio Datos incluido en el directorio Programa
de la unidad C (primera unidad de disco duro)

Si no se indicase la sección <nombreUnidad>: se tomaría como unidad del fichero la

denominada unidad actual, que no es más que la unidad desde la que se le referencia.
Por tanto, \leeme.txt será el fichero leeme.txt de la unidad actual, , y \ será el
directorio raíz de dicha unidad.

En caso de que se desee especificar un fichero que esté ubicado en una máquina remota,
entones para hacerle referencia hay que usar el formato UNC1, cuya sintaxis es:

\\<nombreServidor>\<nombreFicheroCompartido>

Por ejemplo, \\pc1\Fuentes\principal.cs haría referencia al fichero principal.cs

de la carpeta compartida Fuentes ubicada en la máquina pc1.

Rutas independientes del sistema operativo

En el epígrafe anterior se explicó el formato de las rutas siguiendo la sintaxis propia de

Windows pero se comentó que la BCL incorpora mecanismos que permiten escribir las
aplicaciones de manera independiente del formato usado por el sistema operativa de la
máquina sobre la que se ejecute el programa. Pues bien, esos mecanismos consisten en
escribir dichas rutas usando las siguientes campos char static readonly del tipo Path:

Campo Parte de la ruta que su valor representa

DirectorySeparatorChar Separador de directorios. En Windows es \, en Unix es / y
Macintosh es :
AltDirectorySeparatorChar Carácter alternativo usable como separador de directorios.
En Windows y Macintosh es /, mientras que en Unix es \
PathSeparator Separador entre rutas. Aunque en los sistemas operativos
más comunes es ; podría variar en otros.
VolumeSeparatorChar Separador de unidades lógicas. En Windows y Macintosh
es : (por ejemplo c:\datos) y en Unix /
Tabla 1: Campos de Path independizadores del formato de rutas de los sistemas operativos

En la versión de la BCL para cada sistema operativo se almacenará en estos campos el

carácter correspondiente en dicho sistema a la parte de la ruta que representan. De esta
manera, si en lugar de escribir directamente la ruta “\datos\datos.dat” escribimos:

String ruta = Path.DirectorySeparatorChar + ”datos” +

Path.DirectorySeparatorChar + ”datos.dat”;

Conseguiremos que la variable ruta almacene el formato de la misma según corresponda

al sistema operativo sobre el que se ejecute el código anterior. Es decir, mientras que en
Windows contendría “\datos\datos.dat”, en Unix contendría “/datos/datos.dat”

1
UNC = Universal Naming Convention o Convenio Universal de Nombrado
Operaciones con rutas

Aparte de la utilidad independizadora del sistema opeartivo vista, Path también es muy
útil porque incluye un conjunto de miembros estáticos específicamente diseñados para
realizar cómodamente las operaciones más frecuentes relacionadas con rutas.

La mayoría de estos métodos toman como parámetros cadenas de texto con las rutas
sobre la que se desean aplicar la operación que facilitan. Si recuerda, como en Windows
el carácter usado como separador de directorios (\) coincide con el que C# usa como
indicador de secuencias de escape, en este lenguaje es incorrecto representar rutas como
c:\datos con literales como “c:\datos”. En su lugar hay tres alternativas:

• Usar el campo independizador del sistema operativo, aunque ello tiene el problema
de que da lugar a códigos poco compacto. Por ejemplo, para la ruta anterior habría
que representarla con “c:”+Path.DirectorySeparatorChar+”\datos”.

• Duplicar los caracteres \ de los literales para que dejen de considerarse secuencias de
escape. Así, la ruta de ejemplo anterior quedaría como “c:\\datos”

• Especificar la ruta mediante un literal de cadena plano, pues en ellos no se tienen en

cuenta las secuencias de escape. Así, ahora la ruta del ejemplo quedaría como
@”c:\datos” Esta será la alternativa que más se usará en el libro ya que para rutas
largas se hace muchos más compacta y fácil de leer al no incluir tantos \ duplicados.

Dicho esto, el primer grupo de métodos que veremos son los destinados a facilitarnos la
extracción de información sobre las diferentes partes de la ruta que se les pase, que son:

• string GetExtension(string ruta): Devuelve la extensión, del fichero o directorio cuya

ruta se le indica incluido el carácter . usado como separador en ella. Así, para una
ruta como @”c:\datos\data.dat” devolvá “.dat” Si sólo nos interesa saber si una ruta
contiene un fichero o directorio con extensión entonces podemos usar en su lugar el
bool HasExtension(string ruta) incluido específicamente para ello.

• string GetFileName(string ruta): Devuelve el nombre del fichero o directorio cuya

ruta se le indica. Por ejemplo, dada la ruta @”c:\datos\data.dat” devolvería “data.dat”

• string GetFileNameWithoutExtension(string ruta): Idem al anterior pero sin devolver

la extensión del fichero. O sea, dada la ruta @”c:\datos\data.dat” devolvería “data”.

• string GetDirectoryName(string ruta): Devuelve la ruta completa del directorio padre

del fichero o directorio cuya ruta se le indica. Por ejemplo, si dicha ruta es
”c:\datos\data.dat” devolverá c:\datos.

• string GetPathRoot(string ruta): Devuelve la raíz de la ruta indicada. Por ejemplo, si

ésta era @“c:\datos\data.dat” devolverá “c:\”. Si sólo queremos saber si la ruta dispone
de raíz podemos usar mejor el bool IsPathRooted(string ruta) incluido para ello.

Aparte de estos métodos también se incluyen otros que permiten hacer tareas de
diversos tipo relacionadas con rutas como:
• Modificar su extensión: El método string ChangeExtension(string ruta, string
nuevaExtensión) puede usarse tanto para cambiar la extensión del directorio o
fichero cuya ruta se le indica como para añadirle una nueva si no tenía ninguna o
quitarle la que tuviese si se le pasa null como nuevaExtensión.

Así, Path.ChangeExtension(@"c:\datos\dato1.dat", “txt”) genera @"c:\datos\dato1.txt",

Path.ChangeExtension(@"c:\datos\dato1", “dat”) produce @"c:\datos\dato1.dat", y
Path.ChangeExtension(@"c:\datos\dato1.dat", null) devuelve @"c:\datos\dato1"

• Obtenerse su versión completa: El método string GetFullPath(string rutaRelativa)

de Path permite obtener la versión completa de la ruta relativa que se le indique. Por
ejemplo, si el directorio actual es d:\temp, al llamarle con Path.GetFullPath(“f.txt”)
devolverá @“d:\temp\f.txt”

• Concatenar rutas: Dadas dos rutas cualesquiera el método string Combine(string

ruta1, string ruta2) devuelve el resultado de combinarlas siempre. Por ejemplo, dada
la llamada Path.Combine(@“c:\datos”, “fichero.txt”) su resulado será “c:\datos\fichero.txt”

Al usar este método tenga cuidado, pues si el resultado de combinar las rutas no da
lugar a una ruta válida no se producirá ninguna excepción, sino que en su lugar se
devolverá el valor indicado como ruta2. Por ejemplo, el resultado de una llamada
como Path.Combine(@“c:\datos”, “@d:\patatas”) es “@d:\patatas”.

Cuando use cualquiera de estos métodos tenga siempre presente una cosa: permiten sólo
operar con cadenas de texto que representan rutas pero no están de en ninguna manera
relacionados con las ruta que representan. Su utilidad es permitir preparar nuevas rutas a
partir de otras ya existentes para luego poder, si se desea, podrán ser pasarse a otros
mecanismos para actuar físicamente sobre ellas. Por ejemplo, modificar una ruta con
ChangeExtension() no implica que la ruta física en el dispositivo no volátil al que esté
asociada quede también modificada, pero la cadena que se devuelva puede usarse luego
para modificarla mediante otros métodos que iremos viendo a lo largo del tema.

Representación de ficheros y directorios en .NET

Elementos comunes

En la plataforma .NET el trabajo con ficheros y directorios se hace, como no, siguiendo
un enfoque orientado a objetos en el que cada se los encapsula dentro de un objetos de
ciertos tipos: los ficheros en objetos FileInfo y los directorios en objetos DirectoryInfo.

Dado que ambos tipos de elementos dispone de muchas características , lo que se ha

hecho en la BCL es definir los tipos envolventes que los representan en base a una clase
abstracta común llamada FileSystemInfo que facilite la escritura de código genérico que
al sólo usar sus características comunes pueda trabajar tanto con unos como con otros.

Según su funcionalidad los miembros comunes ofrecidos por esta clase se agrupan en:
• Determinación de existencia: Saber si existe físicamente o el fichero o directorio
representado por un objeto FileSystemInfo es tan sencillo como mirar el valor de su
propiedad bool Exists.

• Borrado: Como tanto los ficheros como los directorios pueden ser borrados, en
FileSystemInfo se proporciona un método Delete() mediante el que es posible borrar
ambos tipos de elementos del sistema de archivos. Sin embargo, al usarlo hay que
tener en cuenta que si el elemento a borrar es un directorio, éste ha de estar vacío
porque si no lanzará una IOException

• Acceso a información: Se ofrecen propiedades de sólo lectura que permiten tanto

obtener cadenas con el nombre completo del fichero o directorio representado
(FullName) como con su nombre principal (Name) o su extensión (Extension)

Como muchos sistemas operativos almacenan información sobre las fechas de

creación, último acceso y última modificación de los ficheros y directorios de su
sistema de archivo, también se proporcionan propiedades (DateTime CreationTime,
DateTime LastAccessTime y DateTime LastWriteTime respectivamente) que permiten
acceder a ellas tanto para leerlas como para modificarlas.

Sin embargo, no todos los sistemas operativos almacenan esta información o si lo

hacen permiten modificarla. Si un sistema operativo no la admite, la lectura de estas
propiedades devolverá null; y si las admite pero no permite modificarlas (como es el
caso de Windows 95 y Windows 98 con los directorios), las escrituras en ellas no
tendrán ningún efecto y serán completamente ignoradas.

• Por otro lado, los sistemas operativos también suelen asociar una serie de atributos a
cada uno de sus ficheros y directorios que describen cómo ha de interpretarse bajo
determinadas circunstancias. Mediante la propiedad Attributes podemos acceder a
ellos tanto para leerlos como para modificarlos. Esta propiedad es de un tipo
enumerado llamado FileAttributes que admite los siguientes literales:

Literal Significa que el fichero o directorio...

Normal Es fichero normal y corriente, sin ningún otro atributo
Directory Es un directorio, no un fichero
Hidden Ha de considerarse como oculto y no mostrarse en los
listados normales del contenido de su directorio padre
System Forma parte del sistema operativo
ReadOnly Es de sólo lectura
Encrypted Está cifrado. Si es un directorio entones los ficheros que
se le añadan se cifrarán automáticamente
Compressed Está comprimido
Temporary Es temporal y será borrado por el sistema operativo
cuando finalice la ejecución de la aplicación que lo creó
Archive Está archivado. Este atributo suelen activarlo las
aplicaciones de backup para marcar los archivos o
directorios de los que se dispone de copias de seguridad
Offline No está disponible debido a que está almacenado en una
máquina remota con la que no se puede conectar
 NotContentIndexed No ha de ser indexado por los servicios de indexado de
contenidos de los que disponga el sistema operativo
SparseFile Es un fichero esparcido, lo que significa que es un fichero
grande cuyo contenido son casi todo ceros.
ReparsePoint Contiene un bloque de datos asociado con información
configurable por el usuario
Tabla 2: Literales indicadores de atributos de ficheros de FileAttributes

Tenga en cuenta que la tabla anterior abarca atributos propios de muy diversos
sistemas operativos que no tienen porqué estar presentes en todos los sistemas
operativo. Además, aunque pueda darle la sensación de que cada fichero o directorio
sólo puede disponer de sólo uno de los atributos señalados porque su propiedad
Attributes devuelve un único objeto, esto no es así porque FileAttributes ha sido
definido como una enumeración de flags y sus objetos pueden almacenar
combinaciones OR de sus literales. Por ejemplo, un método que convierta ficheros o
directorios en ocultos y de sólo lectura puede escribirse así:

public void ConvierteEnOcultoDeSoloLectura(FileSystemInfo f)

{
f.Attributes = FileAttributes.Hidden | FileAttributes.ReadOnly;
}

Dado que los atributos asociados a un fichero pueden ir cambiando dinámicamente,

es importante que siempre que se acceda a ellos se obtenga una versión actualizada
de los mismos. Para conseguirlo basta llamar al método Refresh() del objeto
FileSystem que lo representa.

A modo de resumen a continuación se muestra un ejemplo de método que hace uso

de todas estas propiedades para mostrar por la consola la información asociada al
fichero o directorio que representa el objeto FileSystemInfo que se le indique:

public static void muestraInfo (FileSystemInfo f)

{
if (f.Exists)
{
Console.WriteLine("Nombre completo: {0}", f.FullName);
Console.WriteLine("Nombre : {0}", f.Name);
Console.WriteLine("Extensión : {0}", f.Extension);
Console.WriteLine("Fecha creación: {0}", f.CreationTime);
Console.WriteLine("Fecha último acceso: {0}", f.LastAccessTime);
Console.WriteLine("Fecha última modificación: {0}", f.LastWriteTime);
Console.WriteLine("Atributos: {0}", f.Attributes.ToString("F"));
}
else
throw new FileNotFoundException();
}

Aunque el trabajo con ficheros y con directorios es muy similar –de hecho, como ya
hemos visto, los tipos que los representan derivan de una clase común FileSystemInfo-,
también es cierto que cada uno de ellos dispone tiene una serie de características propias
que lo diferencian del otro. Por esta razón, en la BCL se ha definido como abstracta
FileSystemInfo y se han incluido subclases suyas no abstractas FileInfo y DirectoryInfo
que añaden a los miembros comunes heredados de su padre miembros relacionados con
funcionalidades particulares de cada tipo de elemento.

Elementos específicos de directorios

Para crear el objeto DirectoryInfo que represente a un determinado directorio basta pasar
como parámetro de su constructor una cadena con la ruta –relativa o completa- del
mismo. Por ejemplo, un objeto d que represente al directorio c:\Pruebas se crea así:
DirectoryInfo d = new DirectoryInfo(@”c:\Pruebas”);

Este directorio no tiene porqué existir, pues como se verá más adelante es posible crear
directorios a través de objetos DirectoryInfo que representen directorios no existentes.

Como ya se ha dicho, este objeto es en realidad de una subclase de FileSystemInfo y por

tanto dispondrá de todos los miembros definidos en ella además de los explícitamente
definidos en DirectoryInfo. Estos miembros adicionales le aportan las funcionalidades
específicas del trabajo con directorios descritas a continuación.

Información adicional sobre el directorio

A la información sobre un directorio que proporciona FileSystemInfo (nombre, fechas,

atributos, etc.), DirectoryInfo añade los siguientes datos:

• Directorio padre: Aunque a partir del nombre completo de un directorio que la

propiedad FullName de FileSystemInfo proporciona puede deducirse con facilidad
cuál es su directorio padre, DirectoryInfo proporciona una propiedad DirectoryInfo
Parent {get;} que permite consultar a esta información con mayor comodidad.

Obviamente no tiene mucho sentido aplicar esta propiedad a un DirectoryInfo que

represente al directorio raíz ya que éste carece de padre, y hacerlo devuelve null.

• Directorio raíz: Si en lugar del padre inmediato de un directorio lo que se desea es

obtener su ancestro más antiguo (directorio raíz) puede consultarse cuál es éste
directamente a través de su propiedad DirectoryInfo Root {get;}

Acceso al contenido de un directorio

Los objetos DirectoryInfo cuentan con métodos con los que pueden obtenerse tablas con
todos los ficheros (FileInfo[] GetFiles()), directorios (DirectoryInfo[] GetDirectories()), o
ficheros y directorios (FileSystemInfo[] GetFileSystemInfos()) contenidos en el directorio
que representan. Por ejemplo, todos los ficheros de c:\Windows pueden obtenerse así:
FileInfo[] ficheros = new DirectoryInfo(@”C:\Windows”).GetFiles();

Cada uno de estos métodos tiene una sobrecarga que admite como parámetro una
cadena con la que pueden filtrarse los nombres de los ficheros o directorios que se
desean obtener. Dicho filtrado consiste en usar los caracteres ? y * como comodines con
los que representar, respectivamente, cualquier carácter y cualquier número de
cualesquiera caracteres. Así por ejemplo, si en vez de todos los ficheros de c:\windows
queremos obtener tan sólo los ejecutables (extensión .exe) podemos hacer lo siguiente:
FileInfo[] ficheros = new DirectoryInfo(@”C:\Windows”).GetFiles(*.exe);

Operaciones típicas de manipulación de directorios

Todo sistema operativo proporciona mecanismos mediante los que sus usuarios pueden
realizar modificar la estructura de directorios del sistemas de archivos de las máquinas,
realizando tareas tales como crear nuevos directorios, eliminar directorios existentes,
etc. Pues bien, para poder realizar este tipo de tareas de una manera automatizada desde
nuestro programas, la clase DirectoryInfo incluye el siguiente conjunto de métodos que
permiten realizarlas programáticamente:

• Creación de directorios: Para crear físicamente el directorio representado por un

objeto DirectoryInfo basta aplicarle al mismo su método Create(). Por ejemplo, para
crear un subdirectorio Test dentro c:\Windows se puede hacer lo siguiente:
new DirectoryInfo(@“c:\Windows\Test”).Create();

Si el directorio a crear de esta forma ya existe no se producirá ninguna excepción.

Simplemente la ejecución de Create() no tendrá absolutamente ningún efecto.

• Borra el directorio vacío representado por el objeto DirectoryInfo sobre el

Delete():
que se aplica. Si ese directorio no está vacío entonces hay que pasarle true como
parámetro para indicar explícitamente que deseamos también borrar su contenido,
pues como mecanismo de seguridad si no lo hiciésemos se lanzaría una IOException

• MoveTo(string directorioDestino): Mueve el directorio y todos sus contenidos al

nuevo directorio que se le indica. Por ejemplo, para trasaladar el contenido de un
directorio c:\Datos1 en otro directorio c:\Datos2 bastaría hacer:
DirectoryInfo d = new DirectoryInfo(@“c:\Datos1”);
d.MoveTo(@“c:\Datos2”);

El directorio de destino especificado no debe existir, pues si no se lanzaría una

IOException. Si lo que se desea es trasladar el contenido de un directorio a otro ya
existente entonces hay que especificar en la llamada a MoveTo() el nombre que se
desea que tenga en el directorio de destino. Es decir, si queremos copiar c:\Datos1
dentro de un directorio c:\Datos2 ya existente entonces habrá que hacer:
DirectoryInfo d = new DirectoryInfo(@“c:\Datos1”);
d.MoveTo(@“c:\Datos2\Datos1”);

Elementos específicos de ficheros

Del mismo modo que para representar específicamente directorios se proporcionan

objetos DirectoryInfo, para representar ficheros se proporcionan objetos FileInfo Este
tipo también desciende de FileSystemInfo y se utiliza de forma similar a los objetos
DirectoryInfo ya vistos. Así por ejemplo, para crear un objeto f de tipo FileInfo que
represente a un fichero c:\winnt\wplog.txt se puede hacer:

FileInfo f = new FileInfo(@”c:\winnt\wplog.txt”);

A través de este objeto se pueden hacer las operaciones típicas de creación (Create()),
borrado (Delete()) y movimiento (MoveTo()) de ficheros de manera análoga a como se ha
visto que se hacen con los directorios. Adicionalmente se ha añadido un método
CopyTo() que funciona de manera similar a MoveTo() sólo que en vez de cambiar al
ubicación del fichero lo que hace es crear una copia del mismo en la ubicación indicada.
De nuevo, para evitar sobreescrituras no deseadas ambos métodos no admiten que el
fichero de destino especificado ya exista lanzan IOExceptions si fuese así, pero ello
también puede cambiarse pasándoles true como segundo parámetro.

En lo referente al acceso a información adicional sobre el fichero hay que señalar que en
este caso la analogía con el caso de los directorios no es tan pura, pues para obtener el
directorio padre de un fichero la propiedad a usar del objeto FileInfo que lo representa
no se llama ahora Parent sino DirectoryName. Además, también se ofrece una segunda
propiedad llamada Directory que permite acceder a esa misma información pero en
forma de objeto DirectoryInfo en lugar de cadena de texto.

Como habrá adivinado, aparte de estos miembros los objetos FileInfo deben también de
ofrecer mecanismos que permitan acceder al contenido de los ficheros que representan,
ya sea para leerlo o para modificarlo. Pues bien, precisamente a explicar cómo se realiza
eso es a lo que esta destinado los siguientes epígrafes.

Flujos de entrada-salida

La forma con la que se trabaja con ficheros en la plataforma .NET está íntimamente
ligada al concepto de flujo de entrada-salida, que consiste en tratar su contenido como
si de una secuencia ordenada de bytes se tratase. Este concepto no está ligado en
exclusividad a los ficheros, sino que es un concepto abstracto aplicable a otros tipos de
almacenes de información tales como conexiones de red o buffers en memoria.

En realidad se distinguen dos tipos de flujos:

• Flujos base: Trabajan directamente con algún tipo de medio físico, como puede ser
una porción de memoria, de espacio en disco o una conexión a red.
• Flujos intermedios: No trabajan con medios físicos directamente sino envuelven a
otros flujos a los que proporcionan diferentes características, pudiéndose combinar
entre sí de manera que el flujo base que haya tras ellos pueda verse beneficiado por
todas las funcionalidades que ofrezcan todas ellos. Ejemplos son los flujos que
proporcionan encriptación de datos o buffers de almacenamiento intermedio.

En la BCL todos los tipos relativos al trabajo con flujos se encuentran agrupados dentro
del espacio de nombres System.IO Un tipo muy importante entre ellos es Stream, que es
la clase abstracta base de todos los flujos y les proporciona los miembros básicos que
permiten trabajar con ellos. Estos miembros se explicarán en los epígrafes que siguen.
Lectura y escritura

Como es lógico, todo flujo dispondrá de mecanismos mediante los que se le puedan
extraer y añadir bytes. No todos los flujos tienen porqué admitir ambas operaciones, por
lo que para saber qué operaciones admite cada flujo concreto Stream añade a todos ellos
dos propiedades bool CanRead y bool CanWrite que permite consultarlo.

Para la lectura se ofrecen métodos ReadByte() y Read() que, respectivamente, permiten

extraerles uno o varios bytes (se almacenarían en una tabla byte[]); y para la escritura se
hace lo mismo con WriteByte() y Write(). Obviamente los métodos de lectura sólo serán
aplicables flujos que admitan lectura y los de escritura sólo serán aplicables a los que
admitan escritura, y si se intentan aplicar a flujos que no los admitan se lanzarán
excepciones NotSupportedException.

Los métodos anteriores funcionan síncronamente, lo que significa que tras llamarlos el
código que los llamó se quedará en espera de que terminen de ejecutarse. Sin embargo,
como las operaciones de entrada-salida suelen ser lentas también se ofrecen parejas de
métodos BeginRead()-EndRead() y BeginWrite()-EndWrite() que permiten realizarlas
asíncronamente de manera que mientras se estén realizando el código llamador pueda
seguir ejecutándose y realizando otras tareas. Estos métodos funcionan análogamente a
como lo hacen las parejas de métodos BeginInvoke y EndInvoke de los delegados.

Tras cada lectura la siguiente llamada a estos métodos devolvería los bytes del flujo
siguientes a los últimos leídos, y para detectar cuando se alcance el final del flujo basta
mirar su valor de retorno, pues en ese caso ReadByte() devolverá un –1 y Read() un 0.
Respecto a la escritura, cada vez que se escriba se escribirá a continuación de los
últimos bytes escritos en el flujo.

Movimiento por el flujo

Por defecto, la primera operación que se realice sobre un flujo se aplica a su comienzo y
las siguientes se aplican tras la posición resultante de la anterior. Es decir, en cada
lectura o escritura se lee o escribe a continuación de la última posición accedida, por lo
que antes de acceder a una determinada posición habrá que pasar antes por las previas.
A esto se le conoce como acceso secuencial.

Sin embargo, hay situaciones en las que puede resultar interesante poderse escribir o
leer de cualquier posición del flujo sin necesariamente tener que pasar antes por sus
anteriores. A esto se le conoce como acceso aleatorio, y como no todos los flujos tienen
porqué admitirlo, cada flujo dispone de una propiedad de sólo lectura bool CanSeek que
indica si lo admite.

Si un flujo admite acceso aleatorio le serán aplicables los miembros de Stream relativos
a dicho tipo de acceso que a continuación se muestran, mientras que si no lo admite la
utilización de los mismos provocará excepciones NotSupportedException:

• long Length {get;}: Número de bytes almacenados en el flujo (tamaño del

flujo)
 • SetLength(long tamaño): Cambia el número de bytes almacenados en el
flujo por el indicado. Si este nuevo tamaño es inferior al que tenía se truncarán
los bytes que no sobren, mientras que si es superior se rellenarán los nuevos
bytes con valores inespecificados y conviene darles a mano valores por defecto.

A diferencia de Length, para poderse ejecutar este miembro no sólo se necesita

que el flujo admita acceso secuencial sino que además se necesita que admita la
realización de operaciones de escritura.
• long Position: Número del byte actual en el flujo. Dándole valores
podemos movernos por el flujo tal y como muestra el siguiente método de
ejemplo:
public void MuestraByte(Stream flujo, long númeroByte)
{
int posiciónAnterior = flujo.Position;

if (númeroByte > flujo.Length)

throw new ArgumentOutOfBoundsException();

flujo.Position = númeroByte;
Console.WriteLine(“Byte {0} = {1}”, númeroByte, flujo.ReadByte());
flujo.Position = posiciónAnterior;
}

Este método imprime en la consola el byte que se le indique del flujo que se le
pase como parámetro. Nótese que, para asegurar que su ejecución sea inocua y
no altere el flujo se controla a su comienzo cuál era la posición inicial en el flujo
y a su final se le restaura a dicha posición. Por otra parte, también se controla
que el númeroByte indicado se encuentre dentro del flujo, pues sino aunque la
asignación flujo.Position = númeroByte sería válida y no produciría excepciones, el
flujo habría quedado en un estado inconsistente y ReadByte() devolvería –1.

• long Seek(long posición, SeekOrigin inicio): Permite colocarnos en un

byte del flujo determinado. La posición de éste se indica de manera relativa
respecto a la posición de inicio señalada por su segundo parámetro, que es de un
tipo de enumeración cuyos posibles literales son Current (posición actual en el
flujo), Begin (inicio del flujo) y End (final del flujo) Por ejemplo:
// Coloca justo antes del comienzo del flujo
flujo.Seek(0, SeekOrigin.Begin);

// Coloca justo después del final del flujo

flujo.Seek(0, SeekOrigin.End);

// No nos movemos de la posición actual

flujo.Seek(0, SeekOrigin.Current);

// Coloca dos bytes a continuación de la posición actual en el flujo

flujo.Seek(2, SeekOrigin.Current);

// Coloca dos bytes antes de la posición actual en el flujo

flujo.Seek(-2, SeekOrigin.Current);

// Coloca en el segundo byte del flujo

flujo.Seek(2, SeekOrigin.Begin);
 // Coloca en el penúltimo byte del flujo
flujo.Seek(-2, SeekOrigin.End);

Volcado de datos en flujos

Muchos flujos trabajan internamente con buffers donde se almacenan temporalmente

los bytes que se solicitan escribir en ellos hasta que su número alcance una cierta
cantidad, momento en que son verdaderamente escritos todos a la vez en el flujo. Esto
se hace porque las escrituras en flujos suelen ser operaciones lentas e interesa que se
hagan el menor número de veces posible.

Sin embargo, hay ocasiones en puede interesar asegurarse de que en un cierto instante
se haya realizado el volcado físico de los bytes en un flujo, ya sea porque de ello
dependa el correcto funcionamiento de otras partes de la aplicación o se sepa que no se
volverá a escribir en él hasta que dentro de mucho. En esos casos puede forzarse el
volcado llamando al método Flush() del flujo, que vacía por completo su buffer interno.

Cierre de flujos

Además de memoria, muchos flujos acaparan recursos extra que interesa liberar una vez
dejen de ser útiles. Por ejemplo, las conexiones de red acaparan sockets y los ficheros
acaparan manejadores de ficheros del sistema operativo, que son recursos limitados y si
no liberarlos podría impedir la apertura de nuevos ficheros o conexiones de red.

Como podrá adivinar, en principio ello es tarea del método Dispose() con el que todo
flujo cuenta como resultado de implementar la interfaz IDisposable que se usa en .NET
como estándar recomendado con el que liberar recursos de manera determinista. Sin
embargo, por similitud con las APIs de manejo de flujos de otros lenguajes a las que
muchos programadores estarán acostumbrados, en .NET la clase Stream también
dispone de un método Close() que hace lo mismo.

En cualquier caso, lo que es importante saber es que una vez cerrado el flujo –ya sea
llamando a Dispose() o a Close()- ya no es posible hacer uso del mismo y cualquier
intento de acceder a sus miembros provocará excepciones ObjectDisposedException

Flujos de entrada-salida en ficheros

El contenido de los ficheros se trata en la plataforma .NET como flujos de entrada-

salida, por lo que para manipularlo se usarán los métodos de Stream ya vistos. Sin
embargo, si recuerda dicha clase es abstracta y por tanto es imposible crear objetos de
ella. Como habrá adivinado, lo que en realidad se hace es usar una subclase suya
especializada en el trabajo con flujos asociados a ficheros. Ésta clase es FileStream.

Creación de objetos FileStream

Creación a partir de objetos FileInfo

A crear el FileStream que permita manipular el contenido de un fichero se le denomina

abrir el fichero, y una forma sencilla hacerlo es mediante el método Open(FileMode
modoApertura) del objeto FileInfo que lo representa. Su parámetro indica qué ha de
hacerse si el fichero a abrir ya existe, y es de un tipo enumerado cuyos literales son:

Literal de FileMode Modo de apertura

Open Abre el fichero presuponiendo existe. Si no fuese así se lanza una
FileNotFoundException.

OpenOrCreate Si el fichero no existe, lo crea

CreateNew Abre el fichero presuponiendo que no existe y creándolo. Si
existiese se lanzaría una IOException
Create Crea el fichero, y si ya existía lo sobreescribe
Truncate Abre el fichero presuponiendo que existe y borrando todo su
contenido. Si no existiese se lanzaría una FileNotFoundException
Append Abre el fichero en modo de concatenación, lo que significa que
sólo podrá escribirse a su final. Si el fichero no existe, lo crea.
Tabla 3: Modos de apertura de ficheros (enumeración FileMode)

Por ejemplo, para abrir un fichero preexistente llamado c:\datos.dat puede hacerse:
FileInfo fichero = new FileInfo(@“c:\datos.dat”);
FileStream contenidoFichero= fichero.Open(FileMode.Open);

Además del modo de apertura, también puede resultar interesante especificar qué es lo
que deseamos hacer con el contenido del fichero: si sólo leerlo, si sólo escribir en él o si
ambas cosas; pues muchos sistemas operativos permiten asociar a los ficheros permisos
de acceso con los que puede restringirse qué puede hacerse con cada uno. Como si no
indicamos nada se considerará que queremos tanto leer como escribir en el fichero, y
para especificar cualquier otra cosa basta pasar a Open() un parámetro adicional del tipo
enumerado FileAccess que indique como se desea abrirlo. Los literales de este tipo son:

Literal de FileAccess Modo de acceso solicitado

Read Sólo lectura del contenido
Write Sólo escritura de contenido
ReadWrite Tanto lectura como escritura de contenido
Tabla 4: Modos de acceso a ficheros (enumeración FileAccess)
Fíjese que algunos modos de aperturas de ficheros, por su propia definición, requieren
de ciertos permisos de acceso. Por ejemplo, un fichero sólo puede abrirse en modo de
concatenación (FileMode.Append) si se tiene permiso de acceso FileAccess.Write; y ni
siquiera se permite abrirlo si se tiene FileAccess.ReadWrite porque es absurdo leer de él.

Un ejemplo de cómo abrir un fichero preexistente en modo de sólo lectura es:

FileInfo fichero = new FileInfo(@“c:\datos.dat”);

FileStream contenidoFichero= fichero.Open(FileMode.Open, FileAccess.Read);
Ahora bien, como es bastante frecuente abrir en modo de sólo lectura o de lectura-
escritura ficheros preexistentes, a los objetos FileInfo también se les ha dotado de un par
de métodos FileStream OpenRead() y FileStream OpenWrite() que permiten, de manera
respectiva, abrir así los ficheros que representan. Por tanto, en el ejemplo anterior en
realidad podría haberse escrito de la siguiente manera mucho más compacta:

FileInfo fichero = new FileInfo(@“c:\datos.dat”);

FileStream contenidoFichero= fichero.OpenRead();

Por otra parte, la mayoría de los sistemas operativos permiten controlar la forma en que
diferentes procesos puede acceder simultáneamente a sus ficheros. Por seguridad, para
evitar problemas de concurrencia no se permite que múltiples hilos puedan compartir
ficheros abiertos con cualquiera de las sobrecargas de Open() vistas. Sin embargo, ello
puede cambiarse especificando un tercer parámetro de tipo enumerado FileShare, cuyos
posibles literales son:

Literal de FileShare Modo de compartición

None No se puede compartir
Read Puede compartirse con hilos que sólo quieran leerlo
Write Puede compartirse con hilos que sólo quieran escribir en él
ReadWrite Puede compartirse con cualquier otro hilo
Tabla 5: Modos de compartición de ficheros (enumeración FileShare)

Creación con el constructor de FileStream

Hasta ahora todas las formas de crear objetos FileStream que hemos visto eran métodos
proporcionados por la clase FileInfo que encapsula ficheros, lo que nos obliga a siempre
tener que crear un objeto de este tipo para poder acceder al contenido de un fichero.
Como ello puede resultar ineficiente, la propia clase FileStream también proporciona
una familia de constructores que permiten crear objetos suyos mucho más directamente.
Así, los siguientes constructores son equivalentes a las tres sobrecargas de Open() vistas:

FileStream(string rutaFichero, FileMode modoApertura)

FileStream(string rutaFichero, FileMode modoApertura, FileAccess modoAcceso)
FileStream(string rutaFichero, FileMode modoApertura, FileAccess modoAcceso,
FileShare modoCompartición)

Por ejemplo, para leer el contenido del fichero c:\datos.dat podemos generar un
FileStream así:

FileStream contenidoFichero = new FileStream(@”c:\datos.dat”, FileMode.Open,

FileAccess.Read);

Manipulación del contenido de los ficheros

Como ya se ha repetido hasta la saciedad, el contenido de los ficheros es tratado en la

plataforma .NET como flujos de entrada-salida representados por objetos FileStream; y
dado que esta clase deriva de Stream (clase padre de todos los flujos), para manipularlo
podemos usar cualquiera de los miembros ya vistos para ésta última.
En principio los ficheros admiten tanto lectura como escritura y movimiento por su
contenido, por lo que las propiedades CanRead, CanWrite y CanSeek de los objetos
FileStream valdrán siempre true y los métodos ReadByte(), Read(), WriteByte(), Write() y
Seek() heredadas de Stream serán plenamente utilizables. Sin embargo, como es obvio,
esto dependerá de cómo hayamos abierto el fichero, pues si por ejemplo lo abrimos en
modo sólo lectura, CanWrite devolverá false y métodos como WriteByte() o Write()
dejarán de funcionar y provocarán NotSupportedExceptions.

Dada la relativa lentitud de las operaciones de acceso a ficheros, para mayor eficiencia
durante su realización se ha optado por asociar un buffer a cada FileStream en el que los
bytes que se soliciten escribir se irán almacenando hasta alcanzar un cierto número para
entonces escribirlos todos de una vez. Por defecto el tamaño de este buffer es de 8192
bytes, pero puede cambiarse usando el siguiente constructor para crear el FileStream:

FileStream(string rutaFichero, FileMode modoApertura, FileAccess modoAcceso,

FileShare modoCompartición, int tamañoBuffer)

Al especificar así un tamaño de buffer hay que tener en cuenta que no conviene darle un
tamaño inferior a 8 bytes, pues sería tan pequeño que prácticamente no se ganaría nada
de eficiencia. Es más, cualquier valor inferior a dicha cantidad que se le dé será
ignorado y se tomará en su lugar un tamaño de 8 bytes.

Lo que si es importante recordar es que debido a este buffer, cuando queramos estar
seguros de que en un momento concreto se haya volcado todo su contenido en el fichero
al que está asociado, hemos de llamar al método Flush() Por cierto, por si lo estaba
pensando: cuando hayamos terminado de usar un FileStream y vayamos a cerrarlo no
tenemos porqué preocuparnos de vaciar este buffer, pues el método Close() usado para
ello se encarga automáticamente de hacerlo.

Nótese que hasta ahora no se ha dicho nada acerca de las versiones asíncronas de los
métodos de lectura-escritura heredados de Stream. Esto se debe a que por defecto el
acceso al contenido de los ficheros se realiza siempre de manera síncrona, aunque se
usen los métodos anteriores. Esto se debe a que para ficheros pequeños es la forma de
acceso más eficiente, que son los más frecuentemente utilizados. Sin embargo, como al
trabajar con ficheros grandes puede resultar más eficiente leerlos asíncronamente para
poder realizar otras tareas mientras tanto, también se permite activar el acceso
asíncrono. Para ello basta crear el FileStream usando el siguiente constructor:

FileStream(string rutaFichero, FileMode modoApertura, FileAccess modoAcceso,

FileShare modoCompartición, int tamañoBuffer, bool asíncrono?)

Aunque el parámetro asíncrono? de este constructor indica si se desea habilitar el acceso

asíncrono al contenido del fichero a través de las parejas de métodos BeginWrite()-
EndWrite(), BeginRead-EndRead(), en realidad nada asegura que vaya a realizarse así
puesto que no todos los sistemas operativos soportan dicho tipo de acceso (por ejemplo,
Windows 9X y Windows ME) y en los que no lo hagan seguirán funcionando de forma
síncrona. Además, si el acceso que se realiza es demasiado pequeño (menos de 64 KB
en Windows) también puede ocurrir que el sistema operativo decida que es más
eficiente realizarlo de manera síncrona. Por estas razones, para poder consultar cómo se
pueden realizar los accesos a cada FileStream éstos disponen de una propiedad llamada
bool isAsync {get;} que indica si se les puede acceder asíncronamente.
Aplicación de ejemplo de acceso a ficheros: visor hexadecimal

A modo de ejemplo que sintetice todo lo visto hasta ahora respecto al acceso a ficheros
y su contenido vamos a desarrollar una sencilla aplicación de consola que actúe como
un visor hexadecimal que muestre toda la información relativa al fichero que se le pase
como argumento al llamarla así como los bytes que contiene. Su código es el siguiente:
using System;
using System.IO;

public class VisorHexadecimal

{
static void Main(string[] args)
{
if (args.Length < 1)
{
Console.WriteLine("Error: Llamada incorrecta. Formato correcto de uso:");
Console.WriteLine("\n\t VisorHexadecimal <rutaFichero>");
Environment.Exit(1);
}

FileInfo fichero = new FileInfo(args[0]);

if (!fichero.Exists)
Console.WriteLine("Error: Fichero {0} no encontrado", args[0]);
else
{
muestraInfo(fichero);
muestraContenido(fichero);
}
}

public static void muestraInfo (FileInfo fichero)

{
Console.WriteLine("Nombre : {0}", fichero.Name);
Console.WriteLine("Extensión : {0}", fichero.Extension);
Console.WriteLine("Nombre completo: {0}", fichero.FullName);
Console.WriteLine("Directorio padre: {0}", fichero.DirectoryName);
Console.WriteLine("Fecha creación: {0}", fichero.CreationTime);
Console.WriteLine("Fecha último acceso: {0}", fichero.LastAccessTime);
Console.WriteLine("Fecha última modificación: {0}", fichero.LastWriteTime);
Console.WriteLine("Atributos: {0}", fichero.Attributes.ToString("F"));
Console.WriteLine("Tamaño: {0}", fichero.Length);
}

public static void muestraContenido(FileInfo fichero)

{
using (FileStream contenido = fichero.OpenRead())
{
if (fichero.Length==0)
Console.WriteLine("Sin contenido");
else
{
byte[] bytesLeidos = new byte[16];
long nBytesLeidos = contenido.Read(bytesLeidos, 0, 16);

while (nBytesLeidos!=0)
{
 // Mostramos posición en el fichero del primer byte de la línea
Console.Write("\n{0:X8}:", contenido.Position-16);

// Mostramos línea de bytes

for (int i=0; i<nBytesLeidos; i++)
Console.Write(" {0:X2}", bytesLeidos[i]);

// Separamos los bytes de sus respectivos caracteres asegurando que siempre

// se mantenga el mismo espaciado entre ellos
for (int i=0; i<16-nBytesLeidos; i++)
Console.Write(" ");
Console.Write(" | ");

// Mostramos caracteres de los bytes de la línea. Los no imprimibles se

// muestran como un carácter de punt (‘.’)
for(int i=0; i<nBytesLeidos; i++)
{
char carácterActual = (char) bytesLeidos[i];
if (Char.IsControl(carácterActual))
Console.Write('.');
else
Console.Write(carácterActual);
}
nBytesLeidos = contenido.Read(bytesLeidos, 0, 16);
Console.WriteLine();
}
}
}
}
}

Como se puede ver, el código de esta aplicación es bastante sencillo: simplemente se

comprueba que se le pase algún argumento y si así se toma como ruta de un fichero del
que se mostrará su información asociada y contenido.

La información asociada se muestra a través del método muestraInfo(), que es similar al

método de ejemplo sólo que también muestra información específica de los ficheros y
no común con los directorios, como el tamaño de su contenido.

Para mostrar el contenido del fichero se usa el método muestraContenido(), que lo abre
en modo de sólo lectura y lee su contenido byte a byte mostrando por pantalla los bytes
así leídos en líneas de 16. Cada una de estas líneas va precedida del número que su
primer byte ocupa en el fichero, para así facilitar la determinación de la ubicación en el
fichero de cada uno de sus bytes, y seguida de la representación de sus bytes en forma
de caracteres, para así facilitar la lectura de ficheros de texto. Por ejemplo, al pasar a
este programa como argumento el propio fichero de su código fuente se mostrará:

Fíjese que no cierra explícitamente el FileStream tras terminar de usarlo. Esto se debe a
que en su lugar se ha usado la novedosa instrucción using de C#, que lo hace
automáticamente (en realidad, el cuerpo de Close() es solo una llamada al método
Dipose() al que llama using) Sin embargo, usando otros lenguajes sí que podría ser
necesario llamar explícitamente a Close()
Control de concurrencia en accesos a ficheros

Ya se ha explicado que a través del parámetro de tipo FileShare del constructor de

FileStream puede controlarse si se permite el acceso concurrente a un fichero en función
del tipo de operaciones que quieran realizarse con él.

Sin embargo, este mecanismo controla de manera global el acceso al fichero y no es

muy eficiente cuando se conoce de antemano qué trozos concretos de cada fichero va a
necesitar cada proceso. Por ello, para estos casos se ha incluido en FileStream la
siguiente pareja de métodos que ofrecen la posibilidad de que cada hilo pueda bloquear
temporalmente el acceso a determinadas secciones de los ficheros:

• Lock(long byteInicial, long nBytes): Bloquea el acceso a la sección del fichero que
comienza en el byteInicial indicado y cuyo tamaño en bytes es nBytes
• Unlock(long byteInicial, long nBytes): Desbloquea el acceso a la sección del fichero
indicada. Si dicha sección no estaba bloqueada no se preocupe, pues no pasará nada.

Acceso nativo a ficheros

Muchos sistemas operativos usan internamente manejadores de archivos para trabajar

con los ficheros, y los FileStream de la plataforma .NET no hacen más que encapsular el
uso de éstos ofreciendo una visión orientada objetos y más cómoda de los mismos. Sin
embargo, este nivel de indirección adicional implica también que la manipulación de los
ficheros será más ineficiente que si se usasen directamente los manejadores de archivos.

Para los casos en que la eficiencia en los accesos a archivos sea crítica, .NET también se
da la posibilidad de trabajar directamente con sus manejadores asociados y podérselos
pasar como parámetros a métodos nativos que trabajen con ellos más eficientemente.
Esto se consigue mediante la propiedad Handle de los objetos FileStream, que devuelve
un objeto System.IntPtr que representa al manejador que encapsula.

Hay que tener en cuenta que los manejadores así devueltos pueden ser utilizados por
ciertas funciones nativas del sistema operativo, como las funciones ReadFile() y
WriteFile() de la API Win32, pero ello no significa que también puedan usarse con
funciones que esperen descriptores de ficheros tales como la fread() de la librería de C.

Recíprocamente, a partir de un manejador de archivo también es posible generar un

FileStream que lo encapsule. Para ello, basta usar cualquiera de las sobrecargas de los
constructores de FileStream que se muestran a continuación:
FileStream(IntPtr manejador, FileAccess modoAcceso)
FileStream(IntPtr manejador, FileAccess modoAcceso, bool dueño?)
FileStream(IntPtr manejador, FileAccess modoAcceso, bool dueño?, int tamañoBuffer)
FileStream(IntPtr manejador, FileAccess modoAcceso, bool dueño?, int tamañoBuffer,
bool asíncrono?)

Aunque la mayoría de los parámetros de estos constructores ya los conoce, dueño? es

nuevo e indica si se ha de considerar que el FileStream que se cree es el dueño del
manejador y por tanto su cierre ha de implicar el cierre de éste también. Por defecto el
primer constructor considera que lo es, y si no desea ocurra esto basta con que utilice
cualquiera de los demás constructores dándole el valor false a dicho parámetro.

Fichero binarios

La forma de acceder a ficheros que hasta ahora hemos visto tiene una seria limitación, y
es que trabaja con la información a nivel de bytes, lo cual no suele ser muy conveniente
en tanto que generalmente en las aplicaciones no suele trabajarse directamente con bytes
sino con objetos más complejos formado por múltiples bytes. Por ejemplo, dado que un
int ocupa 4 bytes, para almacenar su valor en un fichero usando un FileStream habría
que realizar una operación WriteByte() por cada uno de sus bytes o descomponer todos
los en una tabla byte[] y escribirlos de una vez con una llamada a Write()

Como esta no es ni por asomo una solución cómoda, en System.IO se han incluido un
par de tipos llamados BinaryReader y BinaryWriter que encapsulan FileStreams y les
proporcionan una serie de métodos con los que se simplifica la lectura y escritura de
objetos de cualquier tipo en ficheros. Aunque similares a flujos intermedios, no hay que
confundir estos tipos con tales, pues aunque encapsulan a otros flujos y disponen de
muchos de los métodos comunes a éstos, no derivan de Stream.

Para crear objetos de estos tipos simplemente basta con pasar como parámetro de sus
respectivos constructores el flujo a envolver, pues éstos son de la forma:
BinaryReader(Stream flujo)
BinaryWriter(Stream flujo)

Una vez encapsulado el flujo siempre es posible extraerlo mediante la propiedad Stream
BaseStream {get;} que ambos tipos de objetos proporcionan para ello.

Los BinaryWriters se caracterizan por disponer de un método Write() con múltiples

sobrecargas que toman parámetros de cualquiera de los tipos básicos excepto object y
los escriben directamente en el flujo que encapsulan.

Análogamente, los BinaryReaders disponen de una familia de métodos ReadXXX() (int

ReadInt(), string ReadString(), etc.) que permiten leer del flujo cualquier tipo básico.
Además, adicionalmente se les ha añadido un método int PeekChar() que permite
consultar el siguiente carácter del flujo en forma de int (o un –1 si no quedasen más)
pero sin extraerlo del mismo, de forma que la siguiente lectura se realizaría como si la
consulta nunca hubiese sido realizada. Sin embargo, quizás por error en el diseño de la
beta 2, no disponen de un método Seek() análogo al que tienen los BinaryWriters2.

Por defecto, se considera que la codificación de las cadenas de texto que se lean o
escriban del flujo es UTF-8, pero puede especificarse cualquier otra usando las
siguientes sobrecargas de sus respectivos constructores:
BinaryReader(Stream flujo, Encoding codificación)
BinaryWriter(Stream flujo, Encoding codificación)

2
De todas formas fíjese que puede seguir haciendo accesos aleatorios a través del método Seek() del
objeto que encapsula, pues éste puede recuperarse a través de la propiedad BaseStream antes comentada
Como se deduce de los prototipos anteriores, la codificación se indica usando objetos
System.Text.Encoding que representarán formatos codificación. Aunque estos objetos
permiten acceder a información sobre los diversos formatos de codificación (página de
código, bits de preámbulo, etc.) y realizar conversiones entre sus juegos de caracteres,
nosotros por ahora sólo los usaremos para indicar el tipo de codificación a usar y los
obtendremos de las siguientes propiedades estáticas de Encoding:

Propiedad Formato que representa el objeto devuelto

ASCII ASCII (7 bits por carácter)
Unicode Unicode (16 bits por carácter) usando notación little-endian
BigEndianUnicode Unicode (16 bits por carácter) usando notación big-endian
UTF8 UTF8 (16 bits por carácter en grupos de 8 bits)
UTF7 UTF7(16 bits por carácter en grupos de 7 bits)
Default Juego de caracteres usado por defecto en el sistema.
Tabla 6: Propiedades indicadores de tipo de codificación incluidas en Encoding

Por ejemplo, para escribir en un flujo que represente a un fichero llamado datos.dat
usando UTF8 al codificar los caracteres puede hacerse lo siguiente:

FileStream fichero = new FileStream(“datos.dat”, FileMode.Create);

BinaryWriter ficheroBinario = new BinaryWriter(fichero, Encoding.UTF8));
ficheroBinario.Write(“Este mensaje se escribirá en UTF8 dentro de datos.dat”);

Del mismo modo, para leer correctamente dicho mensaje habría que hacer algo como:

FileStream fichero = new FileStream(“datos.dat”, FileMode.Open);

BinaryReader ficheroBinario = new BinaryReader(fichero, Encoding.UTF8));
Console.WriteLine(“Leido de datos.dat: {0}“, ficheroBinario.ReadString());

Lo que es importante es tener en cuenta que la codificación a usar al leer los caracteres
de un fichero de texto debería ser siempre la misma que la que se usó para escribirlos en
él, pues si no podrían obtenerse resultados extraños al interpretarse mal los datos leídos.

Ficheros de texto

Ya se ha visto que a través de los objetos BinaryReader y BinaryWriter pueden leerse o

escribirse textos en ficheros mucho más cómodamente que trabajando a nivel de bytes
con sus caracteres, como se haría usando directamente FileStreams. Sin embargo, la
BCL proporciona otra pareja de tipos llamados TextReader y TextWriter con los que
estas tareas se hacen incluso más sencillas.

Lectura de ficheros de texto

Para facilitar la lectura de flujos de texto TextReader ofrece una familia de métodos que
permiten leer sus caracteres de diferentes formas:

• De uno en uno: El método int Read() devuelve el próximo carácter del flujo como, o
un –1 si se ha llegado a su final. Tras cada lectura la posición actual en el flujo se
 mueve un carácter hacia delante, y por si sólo quisiésemos consultar el carácter
actual pero no pasar al siguiente también se ha incluido un método int Peek() que
funciona como Read() pero no avanza la posición en el flujo tras la lectura.

• Por grupos: El método int Read(out char[] caracteres, int inicio, int nCaracteres) lee
un grupo de nCaracteres y los almacena a partir de la posición inicio en la tabla que se
le indica. El valor que devuelve es el número de caracteres que se hayan leído, que
puede ser inferior a nCaracteres si el flujo tenía menos caracteres de los indicados o
un –1 si se ha llegado al final del flujo. También se incluye un método ReadBlock()
que funciona de forma parecida al anterior pero que se queda a la espera de nuevos
caracteres si en el flujo no hay disponibles nCaracteres pero se espera que lleguen,
lo que puede ocurrir cuando se lee de flujos asociados a una conexiones de red.

• Por líneas: El método string ReadLine() devuelve la cadena de texto correspondiente

a la siguiente línea del flujo o null si se ha llegado a su final. Por compatibilidad con
los sistemas operativos más frecuentemente usados, considera que una línea de texto
es cualquier secuencia de caracteres terminada en ’\n’, ‘\r’ ó “\r\n”, aunque la cadena
que devuelve no incluye dichos caracteres.

• Por completo: Un método muy útil que se ha incluido en la BCL y que las librerías
de muchos otros lenguajes y plataformas no tienen es string ReadToEnd(), que nos
devuelve una cadena con todo el texto que hubiese desde la posición actual del flujo
sobre el que se aplica hasta el final del mismo (o null si ya estábamos en su final)

Como la mayoría de estos métodos modifican la posición actual en el flujo pueden darse
problemas de concurrencia si varios hilos usan a la vez un mismo TextReader. Para
evitarlos se ofrece un método estático TextReader Synchronized(TextReader textreader)
que devuelve una versión del TextReader que se le pasa como parámetro en la que se
asegura la exclusión mutua en el acceso a aquellos miembros suyos que podrían dar
problemas al usarlos en entornos concurrentes.

Aparte de estos métodos, los TextReaders también incluyen un método Close() mediante
el que pueden liberarse los recursos que hubiesen acaparado para poder leer de la fuente
que tuviesen asociada. Obviamente, tras llamar a este método no se podrá seguir usando
el TextReader para leer de dicha fuente, e intentar de hacerlo provocará IOExceptions.

En realidad TextReader es una clase abstracta que define características comunes a

objetos capaces de extraer texto de fuentes genéricas. Nosotros para leer ficheros lo que
usaremos serán objetos de su subclase StreamReader especializada en la extracción de
texto de flujos. Sus constructores básicos son:
StreamReader(Stream flujo)
StreamReader(Stream flujo, Encoding codificacion)
StreamReader(Stream flujo, bool autodetectarCodificación?)
StreamReader(Stream flujo,Encoding codificacion,bool autodetectarCodificación)
StreamReader(Stream flujo,Encoding codificacion,bool autodetectarCodificación,
int tamañoBuffer)

Como se ve, estos constructores permiten crear el StreamReader a partir del flujo cuyo
lectura facilitan (puede luego recuperarse leyendo su propiedad Stream BaseStream
{get;}) y que pueden configurarse para usar un cierta codificación y tamaño de buffer
La codificación tomada por defecto es UTF-8, aunque puede cambiarse dándole el valor
apropiado al parámetro codificación. Además, también se incluye un parámetro llamado
autodetectarCodificación que indica si se desea que se deduzca la codificación del texto a
partir de los valores de sus primeros bytes. Si no pudiese autodetectarse se consideraría
que es la indicada en codificación ó UTF-8 en su defecto. En cualquier caso, siempre es
posible saber cuál es la codificación considerada a través de la propiedad Encoding
CurrentEncoding {get;} del StreamReader, pero al leerla hay que tener en cuenta que su
valor puede cambiar tras la primera lectura como consecuencia de una autodetección

El tamaño del buffer que internamente usarán los StreamReaders para alojar los
caracteres que lean es por defecto de 256 caracteres (4096 bytes) Sin embargo, dicho
tamaño puede cambiarse al crearlos indicando su tamaño–en número de caracteres- en
el parámetro tamañoBuffer de su constructor. Dicho valor ha de ser de menos 128 (2048
bytes), y si se le diese alguno menor sería ignorado y se tomaría el mínimo señalado.

La existencia de un buffer implica que pueda ocurrir que haya momentos en los que la
posición actual en el StreamReader sea distinta a la posición actual en su Stream interno
debido a que se hayan leído más caracteres de los solicitados con la idea de guardar
temporalmente los sobrantes en el buffer por si se solicita en breve su lectura. Además,
los StreamReaders suponen que a su flujo interno sólo se accederá a través de ellos, por
lo que si se le hiciesen cambios externamente podrían no verlos directamente por estar
leyendo de su buffer interno. Para resolver los problemas de inconsistencia que esto
podría provocar, todo StreamReader cuenta con un método DiscardBufferedData() que
vacía por completo dicho buffer.

Como un uso muy frecuente de los StreamReaders es extraer textos de ficheros, también
se han definido versiones de cada uno de los constructores anteriormente vistos que en
lugar de tomar como primer parámetro un Stream lo que toman es la cadena con la ruta
del fichero a leer y a partir de ella generan el Stream apropiado. Éstos son:

StreamReader(string rutaFichero)
StreamReader(string rutaFichero, Encoding codificacion)
StreamReader(string rutaFichero, bool autodetectarCodificación?)
StreamReader(string rutaFichero, Encoding codificacion,
bool autodetectarCodificación?)
StreamReader(string rutaFichero, Encoding codificacion,
bool autodetectarCodificación?, int tamañoBuffer)

Aplicación de ejemplo de lectura de ficheros de texto: visor de texto

A modo de ejemplo de cómo de sencillo es leer ficheros con un StreamReader, a

continuación se muestra el código de un visor de ficheros de texto que muestra todo el
texto contenido del fichero cuya ruta se le pasa como argumento:
using System;
using System.IO;

public class VisorTexto

{
static void Main(string[] args)
{
 try
{
if (args.Length < 1)
{
Console.WriteLine("Error: Llamada incorrecta. Formato correcto de uso:");
Console.WriteLine("\n\t VisorTexto <rutaFichero>");
Environment.Exit(1);
}

String nombreFichero = args[0];

StreamReader contenido = new StreamReader(nombreFichero, true);
Console.WriteLine("Contenido de {0}:\n{1}", nombreFichero, contenido.ReadToEnd());
}
catch (FileNotFoundException)
{ Console.WriteLine("Error: Fichero {0} no encontrado", args[0]); }
}
}

Nótese cómo ahora la extracción del contenido del fichero es mucho más sencilla que en
el caso de trabajar directamente con el FileStream asociado al contenido del fichero,
habiéndose reducido el complejo método muestraContenido() del visor hexadecimal de la
anterior aplicación de ejemplo a una única llamada a ReadToEnd() en ésta.

Escritura en ficheros de texto

Del mismo modo que los TextReaders facilita la lectura de textos procedentes de fuentes
genéricas, los TextWriters hace lo propio con la escritura en destinos genéricos. Para ello
ofrece métodos que permiten:

• Escribir cadenas de texto: Todo TextWriters cuenta con método Write() que permite
escribir cualquier cadena de texto en el destino que tengan asociado. Esta cadena se
les pasa como primer parámetro, pero no tiene porqué ser un string sino que puede
ser un objeto de cualquier tipo y lo que se haría sería aplicarle su método ToString()
para obtener su representación en forma de cadena de texto.

También puede pasársele como parámetro una tabla char[], en cuyo caso lo que se
escribiría serían todos sus caracteres en el mismo orden en que apareciesen en ella.
Si además se usa la sobrecarga Write(char[] caracteres, int posición, int n) se podría
delimitar los caracteres de la tabla para sólo escribir los n primeros incluidos a partir
de la posición de la tabla indicada.

Como pasa con el Write() de Console, también existe sobrecarga de este método que
toma como parámetros la cadena a mostrar y un número indefinido de objetos cuya
representación como cadenas se escribirá en el destino en el lugar correspondiente a
las subcadenas {i} de la cadena que se le pasó como primer parámetro.

• Escribir líneas de texto: Aparte de Write(), todo TextWriter también dispone de un

método WriteLine() que funciona igual que el anterior pero añade en su destino
asociado un indicador de fin de línea tras la cadena que se le solicita escribir en él.

Dado que el indicador de fin de línea depende de cada sistema operativo, todo
TextWriter dispone de una propiedad string NewLine mediante la que podemos
 configurar cuál queremos que se use al escribir en su destino asociado. Su valor por
defecto es el “\r\n” correspondiente al indicador de fin de línea en Windows, pero
también puede dársele el valor “\n” correspondiente a Linux3.

Cuando se usen cualquiera de estos métodos hay que tener cuidado con los objetos con
valor null que se les pasen, pues no escriben nada en su lugar en el destino del
TextWriter pero tampoco lanzan ningún tipo de excepción que informe de ello.

Además, también hay que tener cuidado al usarlos en entornos concurrente ya que si
varios hilos usan a la vez un mismo TextWriter podrían presentarse problemas de
concurrencia. Para evitarlos, a partir del TextWriter puede generarse una versión suya
donde se asegure la exclusión mutua al acceder a sus miembros conflictivos llamando
para ello a su método estático TextWriter Synchronized(TextWriter textwriter)

Aparte de los métodos anteriores, todo TextWriter también incorpora el típico método
Close() mediante el que pueden liberarse los recursos que hubiese acaparado para ser
capaz de escribir en su destino asociado. Además, como para optimizar dichas escrituras
las realizan a través de un buffer intermedio, también cuentan con el método estándar
Flush() encargado de vaciarlo para cuando, sin necesidad de cerrar el TextWriter, se
necesite asegurar el volcado físico de todo lo escrito a través de él.

Como TextReader, la clase TextWriter es en realidad abstracta y nosotros para usar la

funcionalidad descrita lo que en realidad usaremos serán objetos de una subclase suya
especializada en la escritura en flujos denominada StreamWriter. Sus constructores
permiten configurar el flujo donde se escribirá, y la codificación y tamaño de buffer a
usar de forma parecida a como se hace en los de StreamReader. Los básicos son:
StreamReader(Stream flujo)
StreamReader(Stream flujo, Encoding codificacion)
StreamReader(Stream flujo, Encoding codificacion, int tamañoBuffer)

Aparte de estos constructores, y como ocurría en los StreamReaders, como es frecuente

usar los StreamWriters para escribir en ficheros de texto también se ofrecen versiones de
ellos que en lugar de tomar como primer parámetro un Stream toma la ruta del fichero a
escribir y a partir de ella generar el Stream apropiado. Éstos son:

StreamReader(string rutaFichero)
StreamReader(string rutaFichero, bool concatenar)
StreamReader(string rutaFichero, bool concatenar, Encoding codificacion)
StreamReader(string rutaFichero, bool concatenar, Encoding codificacion,
int tamañoBuffer)

Como se ve, éstos constructores toman un parámetro adicional llamado concatenar. Este
parámetro permite indicar qué ha de hacerse si el fichero donde se desea escribir ya
existe. Si vale false será sobreescrito, pero si vale true se concatenarán a su final los
nuevos datos que se escriban en él. Por defecto vale true.

Aparte de los miembros de TextWriter ya explicados, los StreamWriters incorporan una

propiedad bool AutoFlush mediante la que es posible conseguir, si se le da el valor true,
que todo texto escrito en él usando sus métodos Write() y WriteLine() sea inmediatamente
3
Aunque puede tomar cualquier otro valor no se recomienda dárselo porque los TextReaders sólo pueden
leer adecuadamente las fuentes de texto cuyos indicadores de fin de línea sean “\r” o “\r\n”
volcado al dispositivo que tiene asociado sin que el programador tenga que acordarse de
llamar explícitamente a Flush() tras cada escritura.

Manipulación del sistema de archivos

Ya hemos visto que mediante objetos FileInfo podemos realizar las tareas más comunes
de manipulación de archivos, acceso a información sobre ellos y a su contenido; y que
mediante objetos DirectoryInfo podemos hacer lo propio con directorios.

Sin embargo, la realización de estas tareas con ellos implica la creación de objetos de
los tipos citados y ello puede llegar a ser un incordio si sólo tenemos que crearlos para
hacer una operación concreta, como por ejemplo renombrar un fichero. Para evitar esto,
la BCL incluye una serie de tipos que sólo tiene métodos estáticos y que actúan como
utilidades que permiten realizar ese tipo de tareas a partir de las rutas de los ficheros en
una sola instrucción, sin tener que andar creando objetos intermedios. El tipo ofrecido
para manipular así ficheros es File, mientras que para los directorios es Directory.

Hay que tener en cuenta que cada vez que se llame a uno de los métodos de estos tipos
se harán las comprobaciones de seguridad necesarias para ver si se tienen los permisos
necesarios sobre los archivos que intervengan en la operación. Sin embargo, cuando se
usan objetos FileInfo o DirectoryInfo las comprobaciones sólo se hacen sobre el fichero o
directorio que ellos representen la primera que se solicite una operación sobre ellos. Por
tanto, para a hacer múltiples operaciones sobre un mismo fichero o directorio es más
eficiente usar objetos intermedios que los métodos estáticos de los tipos anteriores.

Aparte de versiones más cómodas de utilizar de los servicios ofrecidos por los objetos
FileInfo y DirectoryInfo, estos tipos también proporcionan nuevos servicios relativos a
ficheros y directorios que permiten realizar tareas tan útiles como navegar por el sistema
de archivos de una máquina u obtener la lista de unidades lógicas de las que dispone.

Manipulación de ficheros

Como ya se ha dicho, el tipo ofrecido en la BCL como utilidad mediante cuyos métodos
estáticos se facilita la realización de las operaciones con ficheros más comunes es File.
Los servicios ofrecidos por los métodos de este tipo pueden agruparse en:

• Acceso a información sobre ficheros: Para manipular directamente la información

que los sistemas operativos almacenan sobre los ficheros de su sistema de archivo
(atributos, fecha de creación, etc) se ofrecen métodos que operan de manera similar
a las propiedades que para ello se vio que ofrecían los objetos FileInfo. Éstos son:

FileAttributes getAttributes(string rutaFichero)

SetAttributes(string rutaFichero, FileAttributes atributos)

DateTime getCreationTime(string rutaFichero)

SetCreationTime(string rutaFichero, DateTime fechaCreación)

DateTime getLastAccessTime(string rutaFichero)

SetCreationTime(string rutaFichero, DateTime FechaÚltimoAcceso)
 DateTime getLastWriteTime(string rutaFichero)
SetWriteTime(string rutaFichero, DateTime FechaÚltimaModificación)

• Acceso al contenido de los ficheros: Para acceder al contenido de los ficheros se

ofrece un método sobrecargado Open() que funciona de igual forma a como lo hace
el Open() de FileStream ya visto pero que toma como primer parámetro su ruta.

Aparte del anterior, también se incluyen métodos FileStream OpenRead(string

rutaFichero) y FileStream OpenWrite(stringrutaFichero) que permiten abrir ficheros
ya existentes en exclusividad y modo de sólo lectura o de lectura-escritura según,
respectivamente, corresponda.

También se ofrecen un método StreamReader OpenText(string rutaFichero) que

funciona de forma parecida a OpenRead() pero en lugar de devolver directamente el
flujo asociado al fichero devuelve un StreamReader facilita su lectura como texto.
Aunque de OpenWrite() no se ofrece un equivalente tan fiel para facilitar la escritura
de texto en el fichero, se incluye un StreamWriter AppendText(string rutaFichero)
que no requiere que el fichero a abrir exista (si no existe lo crea) y que si existe, en
vez de sobreescribirlo lo que hace es concatenar a su final el texto que se le escriba.

• Modificación de los ficheros del sistema de archivos: Finalmente, se incluye un

tercer grupo de métodos que permiten realizar de una manera cómoda operaciones
tan frecuentes como crear, borrar o mover ficheros por el sistema de archivos.

Para crear ficheros se incluye el método FileStream Create(string rutaFichero), que

nótese que devuelve un FileStream. Este objeto lo devuelve porque tras crearlo lo
más normal es que interese añadirle datos a través de él. Además, se ofrece una
sobrecarga del mismo que toma como segundo parámetro un int que se interpretará
como el tamaño que ha de tener el buffer que dicho FileStream usará internamente.

Antes crear un fichero puede que nos interese ver si previamente ya existía, pues si
fuese así se borraría el existente. Para ello puede usarse el método estático bool
Exists(string rutaFichero) también incorporado en File.

Si lo que se desea es trasladar la ubicación de un fichero en el sistema de archivos

entonces el método a usar es Move(string rutaFuente, string rutaDestino) Nótese que
este método también puede usarse para cambiar el nombre del fichero, pues ese sería
el efecto que se conseguiría si el directorio que se especificase rutaDestino fuese el
mismo que el directorio donde estaba el fichero.

Si en vez de cambiarlo de ubicación lo que queremos es crear una copia suya en otra
ruta, entonces el método a usar es Copy(string rutaFuente, string rutaCopia) Cuando
se use hay que tener cuidado con que el fichero rutaCopia no exista, pues para evitar
sobreescrituras no deseadas se lanzaría una IOException en caso de que existiese.
Otra posibilidad sería pasarle true como tercer parámetro a Copy() para así indicar
explícitamente que deseamos sobreescribirlo.

Finalmente, para borrar ficheros se ofrece un método Delete(string rutaFichero)

Manipulación de directorios

Como también ya se ha comentado, la clase Directory centraliza todo tipo de servicios

relativos a la manipulación de directorios y permite utilizarlos de una manera rápida y
cómoda, sin necesidad de tener que andar creando objetos DirectoryInfo intermedios. En
general, estos servicios que ofrece podemos agruparlos en tres grandes categorías:

• Acceso a información sobre directorios: Igual que, como se ha visto, File cuenta
con miembros que permiten acceder a la información que cada sistema operativo
almacenan sobre los ficheros de su sistema de archivos, Directory hace lo propio con
la relativa a los directorios. Para ello, ofrece los siguientes métodos:

DateTime getCreationTime(string rutaDirectorio)

SetCreationTime(string rutaDirectorio, DateTime fechaCreación)

DateTime getLastAccessTime(string rutaDirectorio)

SetCreationTime(string rutaDirectorio, DateTime FechaÚltimoAcceso)

DateTime getLastWriteTime(string rutaDirectorio)

SetWriteTime(string rutaDirectorio, DateTime FechaÚltimaModificación)

• Acceso al contenido de los directorios: Como sabemos, todo directorio puede

contener múltiples ficheros y/o otros directorios. Pues bien, para obtener la lista de
nombres de todos los ficheros contenidos en un cierto directorio puede usarse el
método estático string[] GetFiles(string rutaDirectorio) de Directory, para obtener la
de sus directorios string[] GetDirectories(string rutaDirectorio), y para obtener la de
sus ficheros y directorios string[] GetFileSystemEntries(string rutaDirectorio)

Los métodos anteriores devuelven listas completas con los nombres de todos los
elementos del directorio correspondientes a cada uno. Por ejemplo, la lista completa
de todos los ficheros contenidos en el directorio C:\Pruebas puede obtenerse así:
String[] contenidoPruebas = File.GetFiles(@”C:\Pruebas”);

Sin embargo, como en ocasiones puede que sólo nos interese obtener los contenidos
del directorio cuyos nombres sigan un cierto patrón, de los métodos anteriores
también se ofrece una sobrecarga que admite como parámetro una cadena que
indique el patrón que han de seguir los nombres a obtener. Este patrón puede usar el
carácter ? para indicar que en su lugar se admite cualquier carácter y el carácter *
para indicar que en su lugar se admite cualquier número (incluido 0) de cualesquiera
caracteres. Así, los nombres de los ficheros almacenados en C:\Pruebas que
empiecen por A y tengan extensión txt pueden obtenerse con:
String[] contenidoPruebas = File.GetFiles(@”C:\Pruebas”, “A*.txt”);

• Navegación por el sistema de archivos: A veces puede interesar escribir las rutas
de los ficheros y/o directorios a los que se quiera acceder de manera relativa a un
determinado directorio, para lo que es necesario ir cambiando de directorio actual.
Esto puede ser útil porque permite que las aplicaciones accedan a ficheros instalados
con ellas sin tener porqué conocer la ruta completa donde se instalaron: se accedería
a los ficheros con rutas relativas a la ubicación de su ejecutable.
 Una segunda utilidad de escribir las rutas relativamente es que ello puede
simplificar mucho las rutas cuando se va a acceder a varios ficheros y/o directorios
ubicados dentro de uno determinado. Por ejemplo, para acceder a varios ficheros
ubicados en d:\pruebas\versión1 lo mejor puede ser establecer ese directorio
como el actual y así podremos referenciarlos sin tener que escribir el nombre de su
directorio padre.

Como se ve, para poder escribir las rutas de los ficheros de manera relativa a otros
directorios puede necesitarse poder cambiar el directorio considerado como actual.
Para ello, Directory proporciona el método estático SetCurrentDirectory(string
rutaNuevoDirectorioActual), y también incluye un string GetCurrentDirectory() que
permite consultar cuál es el en cada instante el directorio considerado como actual.

Para ayudarnos en nuestros movimientos a través de los árboles de directorios se

ofrece también un método DirectoryInfo GetParent(string rutaDirectorio), que
devuelve el objeto DirectoryInfo que representa al padre del directorio indicado.

Hay sistemas operativos que trabajan con múltiples unidades de disco lógicas, que
se corresponden con los distintos dispositivos de almacenamiento de la máquina
sobre la que corren o con porciones lógicas de ellos y que tendrán su propio árbol de
directorios. Para facilitar la navegación en estos casos, en Directory se ha incluido
un método string GetDirectoryRoot(string rutaDirectorio) que devuelve el nombre del
directorio raíz del árbol asociado a la unidad de disco a la que pertenece al directorio
indicado en el formato <nombreUnidad>:\; y un método string[] GetLogicalDrives()
que devuelve una tabla con los nombres, en el formato anterior, de todas y cada una
de las unidades de disco lógicas de la máquina sobre la que se ejecuta.

• Modificación de los directorios del sistema de archivos: Para realizar las típicas
operaciones de creación, borrado y movimiento de directorios la clase Directory
incluye los métodos estáticos DirectoryInfo CreateDirectory(string rutaDirectorio),
Delete(string rutaDirectorio) y Move(string rutaFuente, string rutaDestino)

Tenga en cuenta que las operaciones que realice sobre un directorio afectan a todos
los ficheros y subdirectorios contenidos en el mismo. Por ello, si borra un directorio
éste ha de estar vacío o si no Delete() producirá una IOException para evitar borrados
accidentales, aunque de todas formas puede pasarle true como segundo parámetro
para indicarle explícitamente su deseo de borrar el contenido del directorio.

Tenga también en cuenta que operaciones como CreateDirectory() o Move() lanzarán

IOExceptions si los directorios a crear (en el caso de Move() sería el de rutaDestino)
ya existen; y que Delete() producirá una DirectoryNotFoundException si el directorio
a borrar no existe. Para comprobar cómodamente la existencia de directorios y evitar
así problemas puede usar el método bool Exists(string rutaDirectorio) de Directory.

Manipulación de rutas

Detección de cambios en el sistema de archivos

A través de objetos FileSystemWatcher la BCL proporciona un servicio de vigilancia del
estado del sistema de archivos mediante el que es posible detectar cualquier cambio que
se produzca en él (creación y borrado de archivos, modificación de sus atributos, etc.) y
asociar código a ejecutar en esos casos. Es tal su potencia que incluso permite detectar
cambios en sistemas de archivos de máquinas remotas.

De servicios como éste pueden especialmente beneficiarse aplicaciones que funcionen

en una línea similar a Microsoft Biztalk Server. Es decir, que tomen datos que se les
coloquen como ficheros en ciertos directorios y los procesen de alguna manera, ya sea
transformándolos, extrayendo información de ellos, pasándolos a otras máquinas, etc.

Ahora bien, al usar FileSystemWatcher tenga en cuenta que tiene ciertas limitaciones:
sólo funciona bajo Windows N 4.0, 2000 ó XP y la detección remota no funciona entre
dos máquinas que usen Windows NT 4.0. Tampoco admite la vigilancia del contenido
de unidades de CD-ROM o DVD, aunque por otra parte ello es lógico en tanto que este
tipo de unidades son de sólo lectura y por tanto nunca se producirán cambios en ellas.

Selección de ficheros a vigilar

La forma más sencilla de indicar qué ficheros y directorios ha de vigilar un objeto

FileSystemWatcher es especificando en su propiedad string Path el directorio que los
contiene. Por ejemplo, el contenido de c:\datos puede vigilarse así:
FileSystemWatcher observador = new FileSystemWatcher();
observador.Path = @”c:\datos”

Otra posibilidad sería especificar directamente el directorio en su constructor:

FileSystemWatcher observador = new FileSystemWatcher(@”c:\datos”);

En ambos casos tenga en cuenta que el observador vigilará el contenido del directorio
que se le ha especificado aunque posteriormente dicho directorio sea renombrado. Ello
lo consigue gracias a que lo que para él lo identifica no es su nombre sino el manejador
que le asocia el sistema operativo, y éste no cambia por mucho que sea renombrado.

Los observadores creados como se ha dicho detectarán los cambios que se produzcan en
cualquiera de los ficheros y subdirectorios del directorio que se les indique, pero si se
desea que sólo se centre en algunos de ellos puede configurarse su propiedad string
Filter para ello. A esta propiedad se le pasaría una cadena en la que se indicaría el patrón
que seguirán los ficheros a vigilar, representando en ella cualquier carácter mediante un
? y cualquier combinación de cualesquiera caracteres con un *. Por ejemplo, para sólo
vigilar los ficheros de extensión txt de c:\datos podría hacerse:

FileSystemWatcher observador = new FileSystemWatcher(@”c:\datos”);

observador.Path=”*.txt”;

Nuevamente, otra posibilidad sería especificar el filtro directamente en el constructor:

FileSystemWatcher observador = new FileSystemWatcher(@”c:\datos”, “*.txt”);

En cualquier caso, hay que señalar que, por eficiencia, cuando se crea un observador
este sólo vigila por defecto el contenido del directorio que se les indique pero no el de
los subdirectorios del mismo. Si queremos que ello también ocurra hay que configurar
explícitamente su propiedad bool IncludeSubdirectories. Por tanto, todo el sistema de
archivos de la unidad C:\ de una máquina podría vigilarse así:

FileSystemWatcher observador = new FileSystemWatcher(@”c:\”);

observador.IncludeSubdirectories;

Nótese que con IncludeSubdirectories indica que desea vigilar no sólo el contenido del
directorio indicado y sus subdirectorios sino también el de los subdirectorios de éstos, y
el de los subdirectorios de los subdirectorios de estos, etc.

En el lado opuesto, también es posible configurar un FileSystemWatcher para que sólo

vigile los cambios que se produzcan en un fichero concreto. Para ello basta asignar a su
propiedad Path la ruta del directorio al que pertenece y a Filter el nombre de ese fichero.
Por ejemplo, para vigilar el fichero c:\datos\dato1.dat puede hacerse:

FileSystemWatcher observador = new FileSystemWatcher(@”c:\datos”, “dato1.dat”);

Selección de cambios a vigilar

Una vez configurados los ficheros que se desean vigilar, los observadores por defecto
sólo vigilan aquellos cambios de tamaño, nombre o fecha de última modificación que se
produzcan en los mismos. Esto puede cambiarse modificando su propiedad NotifyFilters
NotifyFilter, en la que se indica cuáles son los cambios ha vigilar usando un objeto de un
tipo enumerado que admite los siguientes literales:

Literal Significa que se detectan cambios en...

Attributes Atributos de ficheros
CreationTime Fecha de creación de ficheros
DirectoryName Nombres de directorios
FileName Nombres de ficheros
LastAccess Fecha de último acceso de ficheros
LastWrite Fecha de última modificación de ficheros
Size Tamaño de ficheros
Security Permisos de seguridad de ficheros
Tabla 7: Significado de los literales de NotifyFilters

Estos literales puede combinarse con operaciones lógicas OR. Por ejemplo, los cambios
de nombre o atributos producidos en los ficheros de c:\datos pueden detectarse con:

FileSystemWatcher observador = new FileSystemWatcher(@”c:\datos”);

observador.NotifiyFilter = NotifyFilters.DirectoryFile | NotifyFilters.Attributes;

Detección síncrona de cambios

Una vez configurados los ficheros a vigilar y los tipos de cambios a detectar, la forma
más sencilla de usar FileSystemWatcher para detectar cambios de ese tipo es usando su
método WaitForChangedResult WaitForChanged( WatcherChangeTypes tipoCambio), lo
que dejaría el código bloqueado en espera de que se produjese algún cambio del tipo
indicado en tipoCambio. Este parámetro es de una enumeración cuyos los literales son:

Literal Tipo de cambio detectado

Changed Cambio en atributos, fechas, tamaño o permisos de seguridad de fichero
Renamed Cambio en nombre de fichero o directorio
Created Creación de fichero o directorio (no incluye renombrado de preexistentes)
Deleted Borrado de fichero o directorio
All Cualquiera
Tabla 8: Literales indicadores de tipo de cambio de WatcherChangeTypes

El objeto WaitForChangedResult que devuelve este método contiene información sobre

el cambio producido a partir de la que podríamos actuar en consecuencia. Su propiedad
string Name {get;} almacena el nombre del fichero o directorio afectado por el cambio,
WatcherChangeTypes ChangeType {get;} el tipo de cambio producido, y string OldName
{get;} su nombre anterior si fue un cambio de renombrado (o null si fue de otro tipo)

Por ejemplo, el siguiente programa se queda en espera de que se realice algún cambio
en c:\test y luego muestra un mensaje indicando el tipo de cambio producido:

using System;
using System.IO;

class EsperaCambio
{
static void Main()
{
if (!Directory.Exists(@"c:\test");
Directory.CreateDirectory(@"c:\test");

FileSystemWatcher observador = new FileSystemWatcher(@”c:\test”);

WatcherChangedResult cambio =
observador.WaitForChanged(WatcherChangesTypes.All);

switch(cambio.ChangeType)
{
case WatcherChangeTypes.Changed:
Console.WriteLine(“Detectado cambio en información sobre {0}”, cambio.Name));
break;
case WatcherChangeTypes.Renamed:
Console.WriteLine(“Detectado renombrado de {0} por {1}”,
cambio.Name, cambio.OldName));
break;
case WatcherChangeTypes.Created:
Console.WriteLine(“Detectada creación de {0}”, cambio.Name,));
break;
case WatcherChangeTypes.Deleted:
Console.WriteLine(“Detectado borrado de {0}”, cambio.Name));
break;
}
}
}
Nótese que el problema de utilizar un mecanismo como este para detectar los cambios
es que deja bloqueado al hilo que llama a WaitForChanged() hasta que se produzca el
cambio, lo que puede reducir mucho el rendimiento de la aplicación si éste tarda en
producirse (o incluso bloquearla si nunca llega a producirse)

Para evitar esto y dar la posibilidad de que se puedan realizar otras tareas mientras llega
el evento puede especificarse un como segundo parámetro de tipo int al llamar a
WaitForChanged() que para indicar el tiempo máximo, en ms., que se de esperarse a que
ocurra el cambio, y si no ocurre pasado ese tiempo finalizará la ejecución del método y
se marcará a true la propiedad bool TimedOut del WaitForChangedResult para indicarlo.

Detección asíncrona de cambios

La opción anterior de acotar el tiempo máximo de espera de WaitForChanged() para

poder realizar otras tareas mientras llegue el cambios esperado permite muchas veces
notables mejoras de eficiencia. Sin embargo, una solución asíncrona donde se indique al
FileSystemWatcher qué ha hacerse ante cada tipo de cambio y se le deje funcionando en
un hilo aparte que se encargará de detectarlos y realizar las acciones apropiadas puede
ser mejor, pues en máquinas con varios procesadores es más eficiente y además da lugar
a códigos más claros donde no se intercalan continuas llamadas a WaitForChanged() con
sus consiguientes esperas acotadas y comprobaciones de TimedOut asociadas.

Para asociar códigos a ejecutar ante cada tipo de cambio detectado FileSystemWatcher
proporciona los siguientes eventos:

Evento Su código asociado se ejecutará cada vez que se produzca...

Changed Cambio en atributos, fechas, tamaño o permisos de seguridad de fichero
Renamed Cambio en nombre de fichero o directorio
Created Creación de fichero o directorio (no incluye renombrado de preexistentes)
Deleted Borrado de fichero o directorio
Tabla 9: Eventos de FileSystemWatcher para respuesta a cambios en el sistema de archivos

La mayoría de ellos del tipo delegado FileSystemEventHandler definido como sigue:

void FileSystemEventHandler(object emisor, FileSystemEventArgs args)

El emisor es el FileSystemWatcher que detectó el evento, mientras que args es donde se

información sobre el fichero o directorio al que afectó el cambio. Esta información
incluye su nombre en una propiedad string Name {get;}, su ruta completa en string
FullPath {get;} y el tipo de cambio detectado en WatcherChangeTypes ChangeType {get}

En realidad no todos los eventos de la Tabla 9 son del tipo FileSystemEventHandler,

sino que en el caso concreto de Renamed su tipo delegado es la subclase del anterior:

void RenameEventHandler(object emisor, RenameEventArgs args)

Esto se debe a que aparte de la información proporcionada por el tipo delegado anterior,
ante un renombrado puede convenir disponer también de información sobre el fichero o
directorio afectado antes de ser renombrardo. Eso es precisamente lo que se aporta el
segundo parámetro de este tipo de delegado, que es de un tipo RenameEventArgs hijo de
FileSystemEventArgs, pues añade propiedades destinadas a almacenar el nombre (string
OldValue {get;}) y ruta completa (string OldFullPath {get;}) del fichero o directorio antes
de ser renombrado.

Un ejemplo de cómo mostrar un mensaje cada vez que se detecte la creación de ficheros
en c:\pruebas con la ruta completa del fichero creado es el siguiente trozo de código:
FileSystemWatcher observador = new FileSystemWatcher(@”c:\pruebas”);
observador.Created += new FileSystemEventHandler(muestraMensaje);

donde el método muestraMensaje() estaría definido como sigue en alguna parte dentro
de la misma definición de tipo a la que perteneciese el código anterior:
void muestraMensaje(object emisor, FileSystemEventArgs args)
{
Console.WriteLine(“Creado fichero {0}”, args.FullPath);
}

Hay que tener en cuenta que una vez asociado los códigos de respuesta a los diferentes
eventos del FileSystemWatcher que queramos controlar hay que poner true su propiedad
bool EnableRaisingEvents para lazar el hilo que hará las detecciones de cambios y
llamadas a los códigos asociados a los eventos. Además, en cualquier momento es
posible parar dicho hilo sin más que volver a poner a false esta propiedad.

FileSystemWatcher ha sido definido como un componente4, por lo que también podrá

crear objetos suyos arrastrándolos desde la caja de herramientas de Visual Studio.NET
hasta su ventana de diseño. Sin embargo, si lo hace tenga cuidado ya que entonces el
valor que se le dará por defecto a su propiedad EnableRaisingEvents es true.

Ejemplo: Cifrador de directorios

A modo de ejemplo de cómo usar FileSystemWatcher asíncronamente a continuación se

muestra un ejemplo de aplicación que encripta todos los ficheros que coloquen en el
directorio que se le pase como parámetro al lanzarla:

using System;
using System.IO;

class Cifrador
{
static void Main(string[] args)
{
try
{
FileSystemWatcher observador = new FileSystemWatcher(args[0]);
observador.Created+=new FileSystemEventHandler(ficheroCreado);
observador.EnableRaisingEvents=true;

Console.WriteLine("Cifrado de {0} activado", args[0]);

Console.ReadLine();

4
Un componente es cualquier tipo que derive de Component. Sin embargo, no es el objetivo de este
tema estudiar cómo se crean componentes y su explicación se posterga a temas posteriores.
 Console.WriteLine("Cifrado de {0} desactivado", args[0]);
}
catch (DirectoryNotFoundException)
{ Console.WriteLine("{0} no es un directorio válido"); }
catch (IndexOutOfRangeException)
{
Console.WriteLine("Error: Llamada incorrecta. Formato correcto de uso:");
Console.WriteLine("Cifrador <rutaDirectorio>");
}
}

static void ficheroCreado(object objeto, FileSystemEventArgs args)

{
if (File.Exists(args.FullPath)) // Sólo ciframos los ficheros. Los directorios no.
{
BinaryReader lectorFichero = new BinaryReader(File.OpenRead(args.FullPath));
long tamañoFichero = lectorFichero.BaseStream.Length;
int[] cifradoFichero = new int[tamañoFichero];

for (int i=0; i<tamañoFichero; i++)

cifradoFichero[i] = lectorFichero.ReadByte() + 3;

lectorFichero.Close();

BinaryWriter escritorFichero = new BinaryWriter(File.OpenWrite(args.FullPath));

for (int i=0; i<tamañoFichero; i++)
escritorFichero.Write((byte) cifradoFichero[i]);

escritorFichero.Close();
}
}
}

Como puede observar el código del programa es muy sencillo, simplemente comprueba
que se le haya pasado como argumento la ruta de algún directorio; y si es así crea un
observador que vigila dicho directorio y que cada vez que se crea algún fichero sobre el
mismo lo cifra incrementado en tres unidades el valor cada uno de sus bytes (el clásico
criptsosistema de César)

Problemas de desbordamientos del buffer de cambios

Cada FileSystemWatcher cuenta con un buffer interno donde encola temporalmente

información sobre cambios producidos en el directorio que vigila mientras estaba
procesando, para así procesarlos en orden en cuanto termine con el que estaba. Ahora
bien, si se encolasen tantos que se saturarse ese buffer y se perdiese la detección de los
que no cupiesen en él, el observador lanzaría un evento ErrorEventHandler Error al que
para tratarlo podríamos asociarle un método con la signatura que sigue:

delegate void ErrorEventHandler(object emisor, ErrorEventArgs args );

Tenga especial cuidado al activar la propiedad IncludeSubdirectories, pues como se ha

dicho implica que se vigile todo el contenido del sistema de archivos ubicado a partir
del directorio indicado en la propiedad Path, y como eso pueden ser muchos archivos es
más fácil que ocurran simultáneamente tantos cambios en ellos que se sature el buffer.
Una forma de evitar errores en estos casos puede ser cambiar el tamaño de este buffer
interno, que por defecto es de 8192 bytes. Para ello puede usarse la propiedad int
InternalBufferSize del FileSystemWatcher, a la que se le ha de dar un valor superior a
4096 y recomendablemente (al menos en máquinas Intel) múltiplo de dicha cantidad.

Otra forma para evitarlos es modificar la propiedad NotifyFilter para restringir el tipo de
cambios a detectar y por tanto reducir así su número. Lo que no se le ocurra nunca es
intentar reducirlos usando Filter para filtrar sólo ciertos archivos de la ruta indicada en
Path, pues el buffer en realidad almacena todos los cambios producidos en dicha ruta,
incluidos los que ocurran sobre los ficheros que no entren en el filtro (sólo que cuando
toque procesar estos serán descartados en lugar de procesados)

Ficheros temporales

Muchos sistemas operativos suelen incluir un directorio que ofrecen a las aplicaciones
como almacén temporal de ficheros que sólo son útiles mientras la aplicación se esté
ejecutando pero que una vez ejecutada carecen de sentido y puede eliminarse.

Como según el tipo de sistema operativo que tenga instalado el usuario o según cómo lo
tenga configurado la ruta de éste puede variar, la BCL incluye un método string
GetTempPath() mediante el que puede obtenerse esta ruta para cada máquina concreta.

Por otra parte, como este directorio es compartido entre múltiples aplicaciones, no es
muy recomendable que creemos en él ficheros con nombres elegidos por nosotros
mismos ya que podrían entrar en conflicto con los ya instalados por otras aplicaciones.
En su lugar, es mejor usar el método string GetTempFileName () de Path, que devuelve
un nombre de fichero temporal que seguro que está libre. Por ejemplo, dado el código:
Console.WriteLine(Path.GetTempFileName());

El resultado de ejecutarlo en mi máquina bajo Windows NT 4.0 es que se muestra por la

ventana de consola c:\TEMP\tmp9C5.tmp, si lo vuelvo a ejecutar sin modificar mi
directorio temporal obtendré c:\TEMP\tmp9C6.tmp, y si lo sigo ejecutando iré
obteniendo nombres similares pero con valores diferente en sus tres dígitos que en cada
caso serán una unidad superior al último obtenido.

En realidad el formato de estos ficheros temporales y su ubicación es lo de menos, pues

son dependientes del sistema operativo y del estado del directorio temporal en cada
momento. Lo que es importante que vea es que precisamente porque no siguen un
patrón fijo es por lo que para trabajar con ellos debería usar los métodos arriba citados.

----------------------------------------------------------------------------------------------------------
FileShare.Inheritable no especificado y no válido al usarlo (provoca excepción de
argumento fuera de rango válido)
----------------------------------------------------------------------------------------------------------
Añadir lo del paso por valor y paso por referencia
----------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------
Añadir consejos sobre cómo crear nuevos tipos de excepciones
----------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------
Añadir que la clase padre ha de ir antes que los interfaces
----------------------------------------------------------------------------------------------------------
Uso de this para resolver acceder a campos que coincidan con el nombre de variables
locales.
----------------------------------------------------------------------------------------------------------
Uso de get/set para tratar datos en formato diferente al de su representación interna

Desde el código de una clase puede llamarase a métodos privados de otros objetos de su
misma clase. Útil para acceder a campos privados en copy-constructors

Otra ventaja de propiedades: al igual que los métodos, ocultan la implementación

interna y facilitan la introducción de cambios en ella.
----------------------------------------------------------------------------------------------------------
El this ya no es obligatorio para llamar a los métodos de un mismo tipo
----------------------------------------------------------------------------------------------------------
Los static readonly no pueden inicializarse en constructores no static