Archivos y directorios: Organizacin de archivos

Gunnar Wolf  IIEc-UNAM

Esteban Ruiz  CIFASIS-UNR
Federico Bergero  CIFASIS-UNR
Erwin Meza  UNICAUCA
ndice

1. Introduccin

2. Concepto de archivo

2.1.

Operaciones con archivos

. . . . . . . . . . . . . . . . . . . . . .

2.2.

Tablas de archivos abiertos

. . . . . . . . . . . . . . . . . . . . .

2.3.

Acceso concurrente: Bloqueo de archivos . . . . . . . . . . . . . .

2.4.

Tipos de archivo

2.5.

Estructura de los archivos y mtodos de acceso

. . . . . . . . . .

10

2.6.

Transferencias orientadas a bloques . . . . . . . . . . . . . . . . .

13

. . . . . . . . . . . . . . . . . . . . . . . . . . .

3. Organizacin de archivos

directorio

3.1.

Evolucin del concepto de

3.2.

Operaciones con directorios

3.3.

Montaje

13
. . . . . . . . . . . . . . . .

13

. . . . . . . . . . . . . . . . . . . . .

18

de directorios . . . . . . . . . . . . . . . . . . . . . . . .

21

4. Sistemas de archivos remotos

23

4.1.

Network File System (NFS) . . . . . . . . . . . . . . . . . . . . .

24

4.2.

Common Internet File System (CIFS)

. . . . . . . . . . . . . . .

25

4.3.

Sistemas de archivos distribudos: Andrew File System (AFS) . .

26

5. Otros recursos

1.

28

Introduccin
De los roles que cumple el sistema operativo, probablemente el que ms

consciente tengan en general sus usuarios es el de la gestin del espacio de

sistema de
archivos. Al da de hoy, todos los usuarios de equipo de cmputo dan por sentado
almacenamiento, esto es, la organizacin de la informacin en un

y comprenden a grandes rasgos la organizacin del espacio de almacenamiento en

un

directorio jerrquico, con unidades de almacenamiento llamadas archivos, de

diferentes tipos segn su funcin. En el presente captulo se revisar la semntica

que compone a este modelo, para en el captulo

?? continuar con los detalles de

la gestin del espacio fsico donde stos estn alojados.

La abstraccin que hoy se conoce como

sistemas de archivos

es una de las

que ms tiempo ha vivido y se ha mantenido a lo largo de la historia de la

computacin, sobreviviendo a lo largo de prcticamente todas las generaciones
de sistemas operativos. Sin embargo, para poder analizar cmo es que el sistema
operativo representa la informacin en el dispositivo fsico, el presente captulo
inicia discutiendo cmo es que esta informacin es comprendida por los niveles
ms altos  Por los programas en espacio de usuario.

Figura 1:

Capas de abstraccin para implementar los sistemas de archivos

La informacin

cruda

tiene que pasar una serie de transformaciones. Yendo

de niveles superiores a niveles ms bajos, un programa estructura sus datos en

archivos, siguiendo el formato

que resulte mas pertinente al tipo de informacin

a representar. Un conjunto de archivos hoy en da es tpicamente representado

en una estructura de

directorios,1 .

Cada dispositivo empleado para almacenar archivos tiene un directorio.

Existen otros mecanismos para su organizacin, pero estos no estn tan ampliamente
difundidos
1

Cuando un sistema opera con ms de un dispositivo fsico, existen principalmente dos mecanismos para integrar a dichos dispositivos en un

archivos virtual,2

sistema de

brindnado al usuario una interfaz uniforme. Por ltimo, los

archivos son una estructura meramente lgica; deben ser convertidos para ser
representados en un

dispositivo de bloques

como los diversos tipos de unidades

aunque esta nomenclatura es a veces incorrecta como

ser abordado en el captulo

??.

discos. Este ltimo paso

Del diagrama presentado en la gura 1, toca al objeto de nuestro estudio

el sistema operativo recibir del espacio de usuario las llamadas al sistema que
presentan la interfaz de archivos y directorios, integrar el sistema de archivos
virtual, y traducir la informacin resultante a un sistema de archivos.
Cabe mencionar que varias de las capas aqu presentadas podran perfectamente ser subdivididas, analizadas por separado, e incluso tratarse de forma
completamente modular  De hecho, este es precisamente el modo en que se
implementan de forma transparente caractersticas hoy en da tan comunes como sistemas de archivos en red, o compresin y cifrado de la informacin. Una
referencia ms detallada acerca de ventajas, desventajas, tcnicas y mecanismos de la divisin y comunicacin entre capas puede ubicarse en el artculo de
Heidemann y Popek (1994).

2.

Concepto de archivo
En primer trmino, un archivo es un

tipo de datos abstracto

 Esto es,

podra verse como una estructura que exclusivamente permite la manipulacin

por medio de una interfaz

orientada a objetos :

Los procesos en el sistema slo

pueden tener acceso a los archivos por medio de la interfaz ofrecida por el sistema

3 La siguiente seccin describe las principales operaciones provistas

operativo.

por esta interfaz.

Para el usuario, los archivos son la
cenamiento: Todo el almacenamiento

unidad lgica mnima al hablar de almapersistente (que sobrevive en el tiempo,

sea a reinicios del sistema, a prdida de corriente o a otras circunstancias en

el transcurso normal de ejecucin) en el sistema al que tiene acceso, se efecta
dentro de archivos; el espacio libre en los diferentes dispositivos no tiene mayor

potencialmente disponible.
volmen (cada medio de almacenamiento), los archivos
disponibles conforman a un directorio, y son tpicamente identicados por un
nombre o una ruta. Ms adelante se presentarn de las diferentes construcciones
existencia fuera de saber que est
Dentro de cada

semnticas que pueden conformar a los directorios.

Esto ser abordado en la seccin 3.3

Como se ver en la seccin ??, esto no es necesariamente as, sin embargo, el uso de
los dispositivos en crudo es muy bajo. Este captulo est enfocado exclusivamente al uso
estructurado en sistemas de archivos.
2
3

2.1.

Operaciones con archivos

Cada sistema operativo denir la interfaz de archivos acorde con su semntica, pero en lneas generales, las operaciones que siempre estarn disponibles
con un archivo son:

Borrar

Elimina al archivo del directorio y, de ser procedente, libera el espacio

del dispositivo

Abrir

Solicita al sistema operativo vericar si el archivo existe o puede ser

creado (dependiendo del modo requerido) y se cuenta con el acceso para

el

modo de acceso al archivo indicado y si el medio lo soporta (por ejemplo,

a pesar de contar con todos los permisos necesarios, el sistema operativo

no debe permitir abrir para escritura un archivo en un CD-ROM u otro
medio de slo lectura). En C, esto se hace con la funcin
Al abrir un archivo, el sistema operativo asigna un

fopen().

descriptor de archivo

que identica la relacin entre el proceso y el archivo en cuestin; estos

sern denidos propiamente en la seccin 2.2.
Todas las operaciones descritas a continuacin operan sobre el descriptor
de archivo, no con su nombre o ruta.

Cerrar

Indica al sistema que

el proceso en cuestin

termin de trabajar con

el archivo; el sistema entonces debe escribir los buers a disco y eliminar la entrada que representa a esta combinacin archivo-proceso de las
tablas activas, invalidando al
descriptor de archivo se usa

descriptor de archivo.

En C, para cerrar un

fclose().

Dado que todas las operaciones se realizan a travs del descriptor de archivo, si un proceso cierra un archivo y requiere seguir utilizndolo, tendr
que abrirlo de nuevo para obtener un nuevo descriptor.

Leer

Si se solicita al sistema la lectura leer de un archivo hacia determinado

buer, ste copia el siguiente

pedazo

de informacin a ste. Este

pedazo

podra ser una lnea o un bloque de longitud denida, dependiendo del

modo en que se solicite la lectura. El sistema mantiene un apuntador a
la ltima posicin leda, para poder

continuar

con la lectura de forma

secuencial.
La funcin que implementa la lectura en C es
que

fread()

entrega el

nmero de caracteres

fread().

Cabe mencionar

especicado; para trabajar

con lneas de texto hace falta trabajar con bibliotecas que implementen
esta funcionalidad, como

Escribir

readline.

Teniendo un archivo abierto, guarda informacin en l. Puede ser que

escriba desde su primer posicin (

truncando

toda la informacin que pudiera ya tener), o

al archivo, esto es, borrando

agregando

al archivo, esto es,

iniciando con el apuntador de escritura al nal del mismo. La funcin C

para escribir a un descriptor de archivo es

fwrite().

Reposicionar
tador,

Tanto la lectura como la escritura se hacen siguiendo a un

apun-

que indica cul fue la ltima posicin del archivo a la que acces

el proceso actual. Al reposicionar el apuntador, se puede

saltar

a otro

punto del archivo. La funcin que reposiciona el apuntador dentro de un

descriptor de archivos es

fseek().

Hay varias otras operaciones comunes que pueden implementarse con llamadas compuestas a estas operaciones (por ejemplo,
implementarse como

crear

copiar

un archivo puede

un archivo nuevo en modo de escritura, abrir en mo-

do de lectura al archivo fuente, e ir

leyendo

de ste y

escribiendo

al nuevo hasta

llegar al n de archivo fuente).

Las operaciones aqu presentadas no son todas las operaciones existentes;
dependiendo del sistema operativo, habr algunas adicionales; estas se presentan
como una base general comn a los principales sistemas operativos.
Vale la pena mencionar que esta semntica para el manejo de archivos presenta a cada archivo como si fuera una

unidad de cinta,

dentro de la cual la

cabeza lectora/escritora simulada puede avanzar o retroceder.

2.2.

Tablas de archivos abiertos

Tanto el sistema operativo como cada uno de los procesos mantienen normalmente

tablas de archivos abiertos. stas mantienen informacin acerca de todos

los archivos actualmente abiertos, presentndolos hacia el proceso por medio de

un

descriptor de archivo ; una vez que un archivo fue abierto, las operaciones que

se realizan dentro de ste no son empleando su nombre, sino que su descriptor

de archivo.
En un sistema operativo multitareas, ms de un proceso podra abrir el
mismo archivo a la vez; lo que cada uno de ellos pueda hacer, y cmo esto impacte
a lo que vean los dems procesos, depende de la semntica que implemente el
sistema; un ejemplo de las diferentes semnticas posibles es el descrito en la
seccin 2.3.
Ahora, por qu estas tablas son mantenidas tanto por el sistema operativo
como por cada uno de los procesos? No lleva esto a una situacin de informacin
redundante?
La respuesta es que la informacin que cada uno debe manejar es distinta.
El sistema operativo necesita:

Conteo de usuarios del archivo

Cuando se solicita, por ejemplo,

desmontar

una particin (por ejemplo, para expulsar una unidad removible) o eliminar un archivo, el sistema debe poder determinar cundo es momento
de declarar la solicitud como

efectuada.

Si algn proceso tiene abierto a

un archivo, y particularmente si tiene cambios pendientes de guardar, el

sistema debe hacer lo posible por evitar que el archivo

desaparezca

de su

visin.

Modos de acceso

Aunque un usuario tenga permisos de acceso a determinado

recurso, el sistema puede determinar negarlo si llevara a una inconsisten-

cia. Por ejemplo, si dos procesos abren un mismo archivo en modo de

escritura, es probable que los cambios que realice uno sobreescriban a los
que haga el otro.

Ubicacin en disco

El sistema mantiene esta infromacin para evitar que ca-

da proceso tenga que consultar las tablas en disco para encontrar al archivo, o cada uno de sus fragmentos.

Informacin de bloqueo

En caso de que los modos de acceso del archivo re-

quieran proteccin mutua, puede implementarse por medio de un bloqueo.

Por otro lado, el proceso necesita:

Descriptor de archivo

Relacin entre el nombre del archivo abierto y el iden-

ticador numrico que maneja internamente el proceso. Un archivo abierto

por varios procesos tendr descriptores de archivo distintos en cada uno
de ellos.
A nivel implementacin, el descriptor de archivo otorgado por el sistema a
un proceso es simplemente un nmero entero, que podra entenderse como

el n-simo archivo empleado por el proceso.4

Permisos

Los modos vlidos de acceso para un archivo. Esto no necesariamente

es igual a los permisos que tiene el archivo en cuestin en disco, sino que
el

subconjunto

de dichos permisos bajo los cuales est operando para este

proceso en particular  Si un archivo fue abierto en modo de slo lectura,

por ejemplo, este campo slo permitir la lectura.

2.3.

Acceso concurrente: Bloqueo de archivos

Dado que los archivos pueden emplearse como mecanismo de comunicacin

entre procesos que no guarden relacin entre s, incluso a lo largo del tiempo,
y para emplear un archivo basta indicar su nombre o ruta, los sistemas operativos multitarea implementan mecanismos de bloqueo para evitar que varios
procesos intentando emplear de forma concurrente a un archivo se corrompan
mutuamente.
Algunos sistemas operativos permiten establecer bloqueos sobre determinadas regiones de los archivos, aunque la semntica ms comn es operar sobre
el archivo entero.
En general, la nomenclatura que se sigue para los bloqueos es:

Compartido (Shared lock )

Podra verse como equivalente a un bloqueo (o

candado ) para realizar lectura  Varios procesos pueden adquirir al mismo

tiempo un bloqueo de lectura, e indica que todos los que posean dicho

candado

tienen la expectativa de que el archivo no sufrir modicaciones.

4 No slo los archivos reciben descriptores de archivo. Por ejemplo, en todos los principales
sistemas operativos, los descriptores 0, 1 y 2 estn relacionados a ujos de datos : respectivamente, la entrada estndar (STDIN), la salida estndar (STDOUT) y el error estndar (STDERR);
si el usuario no lo indica de otro modo, la terminal desde donde fue ejecutado el proceso.
6

Exclusivo (Exclusive lock ) Un bloqueo o candado exclusivo puede ser adquirido

por un slo proceso, e indica que realizar operaciones que modiquen al
archivo (o, si la semntica del sistema operativo permite expresarlo, a la

porcin

del archivo que indica).

Respecto al

mecanismo

de bloqueo, hay tambin dos tipos, dependiendo de

qu tan explcito tiene que ser su manejo:

Mandatorio u obligatorio (Mandatory locking )

Una vez que un proceso

adquiere un candado obligatorio, el sistema operativo se encargar de

imponer las restricciones corresponidentes de acceso a todos los dems
procesos, independientemente de si stos fueron programados para considerar la existencia de dicho bloqueo o no.

Consultivo o asesor (Advisory locking )

Este tipo de bloqueos es manejado

cooperativamente entre los procesos involucrados, y depende del programador de

cada uno

de los programas en cuestin el solicitar y respetar

dicho bloqueo.
Haciendo un paralelo con los mecanismos presentados en el captulo

??, los

mecanismos que emplean mutexes, semforos o variables de condicin seran

consultivos,

y nicamente los que emplean monitores (en que la nica manera

de llegar a la informacin es a travs del mecanismo que la protege) seran

mandatorios.

No todos los sistemas operativos implementan las cuatro posibles combinaciones (compartido mandatorio, o compartido compulsivo, exclusivo mandatorio
y exclusivo consultivo). Como regla general, en los sistemas Windows se maneja
un esquema de bloqueo obligatorio, y en sistemas Unix es de bloqueo consultivo.

Cabe mencionar que el manejo de bloqueos con archivos requiere del mismo
cuidado que el de bloqueo por recursos cubierto en la seccin

??: Dos procesos

intentando adquirir un candado exclusivo sobre dos archivos pueden caer en un

bloqueo mutuo tal como ocurre con cualquier otro recurso.

2.4.

Tipos de archivo

Si los archivos son la

unidad lgica mnima con la que se puede guardar infor-

macin en almacenamiento secundario, naturalmente sigue que existen archivos

de diferentes tipos: Cada archivo podra ser un documento de texto, un binario
ejecutable, un archivo de audio o video, o un largusimo etcetera, e intentar
emplear a un archivo como uno de un tipo distinto puede resultar desde una

5 Esto explica por qu en Windows es tan comn que el sistema mismo rechace hacer
determinada operacin porque el archivo est abierto por otro programa (bloqueo mandatorio
compartido), mientras que en Unix esta responsabilidad recae en cada uno de los programas
de aplicacin

frustracin al usuario porque el programa no responde como ste quiere, hasta

en prdidas econmicas.

Hay tres estrategias principales para que el sistema operativo reconozca al

tipo de un archivo:

Extensin

En los sistemas CP/M de los 1970, el nombre de cada archivo se

divida en dos porciones, empleando como elemento separador al punto:

El nombre del archivo y su extensin. El sistema mantena una lista de
extensiones conocidas, para las cuales sabra cmo actuar, y este diseo se
extendera a las aplicaciones, que slo abriran a aquellos archivos cuyas
extensiones supieran manejar.
Esta estrategia fue heredada por VMS y MS-DOS, de donde la adopt
Windows; ya en el contexto de un entorno grco, Windows agrega, ms
all de las extensiones directamente ejecutables, la relacin de extensiones
con los programas capaces de trabajar con ellas, permitiendo invocar a un
programa con slo dar doble click en un archivo.
Como nota, este esquema de asociacin de tipo de archivo permite ocultar las extensiones toda vez que ya no requieren ser del conocimiento del
usuario, sino que son gestionadas por el sistema operativo, abre una va
de ataque automatizado que se populariz en su momento: El envo de
correos con extensiones engaosas duplicadas  Esto es, el programa maligno (un

programa troyano )

se enva a todos los contactos del usuario

infectado, presentndose por ejemplo como una imgen, con el nombre

inocente.png.exe.

Por el esquema de ocultamiento mencionado, ste

se presenta al usuario como

inocente.png,

pero al abrirlo, el sistema

operativo lo reconoce como un ejecutable, y lo ejecuta en vez de abrirlo

en un visor de imgenes.

Nmeros mgicos

La alternativa que emplean los sistemas Unix es, como

siempre, simple y

elegante,

aunque indudablemente presenta eventuales

lagunas: El sistema mantiene una lista compilada de las

huellas digitales

7 para reconocer el contenido

de los principales formatos que debe manejar,

de un archivo basado en sus primeros bytes.

Casi todos los formatos de archivo incluyen lo necesario para que se lleve
a cabo este reconocimiento, y cuando no es posible hacerlo, se intenta

heursticas. Por
formato de intercambio grco

por medio de ciertas reglas

ejemplo, todos los archivos

de imgen en

(GIF) inician con la cadena

GIF87a

GIF89a,

dependiendo de la versin; los archivos del lenguaje

de descripcin de pginas PostScript inician con la cadena %!, el

Formato

6 Por ejemplo, imprimir un archivo binario resulta en una gran cantidad de hojas intiles,
particularmente tomando en cuenta que hay caracteres de control como el ASCII 12 (avance
de forma, form feed ), que llevan a las impresoras que operan en modo texto a iniciar una
nueva pgina; llevar a un usuario a correr un archivo ejecutable disfrazado de un documento
inocuo,
como se ver a continuacin, fue un importante vector de infeccin de muchos virus.
7 Una de las ventajas de este esquema es que cada administrador de sistema puede ampliar
la lista con las huellas digitales que requiera localmente

de Documentos Porttiles

(PDF) con %PDF, etctera. Un documento en

formatos denidos alrededor de XML inicia con

estos formatos no estn

anclados

<!DOCTYPE.

Algunos de

al inicio, sino que en un punto especco

del primer bloque.

Un caso especial de nmeros mgicos es el llamado

hashbang (#!).

Es-

to indica a un sistema Unix que el archivo en cuestin (tpicamente

un archivo de texto, incluyendo cdigo fuente en algn lenguaje de

script )

debe tratarse como un ejecutable, y empleando como

al comando indicado inmediatamente despus del

hashbang.

intrprete

Es por esto

que se pueden ejecutar directamente, por ejemplo, los archivos que inician con #!/usr/bin/bash: El sistema operativo
/usr/bin/bash, y le especica como argumento al

Metadatos externos

invoca al programa
archivo en cuestin.

Los sistemas de archivos empleado por las Apple Mac-

intosh desde 1984 separan en dos

divisiones (forks )

la informacin de un

archivo: Los datos que propiamente constituyen al archivo en cuestin

son la

divisin de datos (data fork ),

acerca del archivo

divisin de recursos

y la informacin

se guardan en una estructura independiente llamada

resource fork ).

Esta idea result fundamental para varias de las caractersticas

al usuario

amigables

que present Macintosh desde su introduccin  Particular-

mente, para presentar un entorno grco que respondiera gilmente, sin

tener que buscar los datos base de una aplicacin dentro de un archivo
de mucho mayor tamao. La

divisin de recursos

cabe en pocos sectores

de disco, y si se toma en cuenta que las primeras Macintosh funcionaban

nicamente con discos exibles, el tiempo invertido en leer una lista de
iconos podra ser demasiada.
La divisin de recursos puede contener todo tipo de informacin; los programas ejecutables son los que le dan un mayor uso, dado que incluyen
desde los aspectos grcos (icono a mostrar para el archivo, ubicacin de la
ventana a ser abierta, etc.) hasta aspectos funcionales, como la traduccin
de sus cadenas al lenguaje particular del sistema en que est instalado.
Esta divisin permite una gran exibilidad, dado que no es necesario tener
acceso al fuente del programa para crear traducciones y temas.
En el tema particular que concierne a esta seccin, la divisin de recursos
incluye un campo llamado

creador,

que indica cul programa fue el que

gener al archivo. Si el usuario solicita ejecutar un archivo de datos, el

sistema operativo lanzara al programa

creador,

indicndole que abra al

archivo en cuestin.
Las versiones actuales de MacOS ya no emplean esta tcnica, sino que una
llamada

appDirectory,

para propsitos de esta discusin, la tcnica base

es la misma.

2.5.

Estructura de los archivos y mtodos de acceso

los archivos.
algn tipo, estructurado o no estructurado.
operativos maneja nicamente archivos sin

La razn principal de la existencia del sistema de archivos son

Un archivo almacena informacin de
La mayor parte de los sistemas

estructura

 Cada aplicacin es responsable de preparar la informacin de

forma congruente, y la responsabilidad del sistema operativo es nicamente entregarlo como un conjunto de bytes. Histricamente, hubo sistemas operativos,
como IBM CICS (1968), IBM MVS (1974) o DEC VMS (1977), que administraban ciertos tipos de datos en un formato bsico de

base de datos.

El hecho de que el sistema operativo no imponga estructura a un archivo

no signica, claro est, que la aplicacin que lo genera no lo haga. La razn
por la que los sistemas creados en los ltimos 30 aos no han implementado
este esquema de base de datos es que le

resta

exibilidad al sistema: El que

una aplicacin tuviera que ceirse a los tipos de datos y alineacin de campos
del sistema operativo impeda su adecuacin, y el que la funcionalidad de un
archivo tipo base de datos dependiera de la versin del sistema operativo creaba
un

acoplamiento

demasiado rgido entre el sistema operativo y las aplicaciones.

Esta prctica ha ido cediendo terreno a dejar esta responsabilidad en manos

de procesos independientes en espacio de usuario (como sera un gestor de bases
de datos tradicional), o de bibliotecas que ofrezcan la funcionalidad de manejo de archivos estructurados (como en el caso de

SQLite,

empleado tanto por

systemtap
fotografas shotwell

herramientas de adquisicin de datos de bajo nivel como

como por

herramientas tan de escritorio como el gestor de

o el nave-

gador

Firefox ).

En los sistemas derivados de MS-DOS puede verse an un remanente de

los archivos estructurados: En estos sistemas, un archivo puede ser

binario.

de texto

Un archivo de texto est compuesto por una serie de caracteres que

lneas, y la separacin entre una lnea y otra constituye de un retorno de

carro (CR, caracter ASCII 13) seguido de un salto de lnea (LF, caracter ASCII

forman

10).

El acceso a los archivos puede realizarse de diferentes maneras:

Acceso secuencial

Mantiene la semntica por medio de la cual permite leer

de nuestros archivos de forma equivalente a unidad de cinta mencionados

en la seccin 2.1, y como lo ilustra la gura 2: El mecanismo principal
para leer o escribir es ir avanzando consecutivamente por los bytes que
conforman al archivo hasta llegar a su nal.
Tpicamente se emplea este mecanismo de lectura para leer a memoria
cdigo (programas o bibliotecas) o documentos, sea enteros o fracciones
de los mismos. Para un contenido estructurado, como una base de datos,

Esta lgica es herencia de las mquinas de escribir manuales, en que el salto de lnea
(avanzar el rodillo a la lnea siguiente) era una operacin distinta a la del retorno de carro
(devolver la cabeza de escritura al inicio de la lnea). En la poca de los teletipos, como medida
para evitar que se perdieran caracteres mientras la cabeza volva hasta la izquierda, se decidi
separar el inicio de nueva lnea en los dos pasos que tienen las mquinas de escribir, para
inducir una demora que evitara la prdida de informacin.
8

10

resultara absolutamente ineciente, dado que no se conoce el punto de

inicio o nalizacin de cada uno de los registros, y probablemente sera
necesario que hacer

barridos secuenciales

del archivo completo para cada

una de las bsquedas.

Figura 2:

Acceso aleatorio

Archivo de acceso secuencial

El empleo de gestores como

SQLite

u otros muchos motores

de base de datos ms robustos no exime al usuario de pensar en el archivo como una tabla estructurada, como lo ilustra la gura 3. Si la nica
semntica por medio de la cual el sistema operativo permitiera trabajar
con los archivos fuera la equivalente a una unidad de cinta, implementar
el acceso a un punto determinado del archivo podra resultar demasiado
costoso.
Afortunadamente, que el sistema operativo no imponga registros de longitud ja no impide que

el programa gestor

cual apunta el descriptor de archivo

FD

lo haga. Si en el archivo al

hay 2000 registros de 75 bytes

cada uno y el usuario requiere recuperar el registro nmero 65 hacia el

registro, puede reposicionar el apuntador de lectura al byte

65 75 = 4875 (seek(FD, 4875)) y leer los siguientes 75 bytes en
registro (read(FD, *registro, 75)).
buer

Figura 3:

Acceso relativo a ndice

Archivo de acceso aleatorio

En los ltimos aos se han popularizado los gestores

dbilmente estructurados u orientados a documentos,

genricamente NoSQL. Estos gestores pueden guardar registros

de base de datos
llamados

de tamao variable en disco, por lo que, como lo ilustra la gura 4, no

11

pueden encontrar la ubicacin correcta por medio de los mecanismos de

acceso aleatorio.
Para implementar este acceso, se divide al conjunto de datos en dos secciones (incluso, posiblemente, en dos archivos independientes): La primer
seccin es una lista corta de identicadores, cada uno con el punto de inicio
y trmino de los datos a los que apunta. Para leer un registro, se emplea
acceso aleatorio sobre el ndice, y el apuntador se avanza a la ubicacin
especca que se solicita.
En el transcurso de un uso intensivo de esta estructura, dado que la porcin
de ndice es muy frecuentemente consultada y relativamente muy pequea,
muy probablemente se mantenga completa en memoria, y el acceso a cada
uno de los registros puede resolverse en tiempo muy bajo.
La principal desventaja de este modelo de indexacin sobre registros de
longitud variable es que slo resulta eciente para contenido

de lectura :

mayormente

Cada vez que se produce una escritura y cambia la longitud

de los datos almacenados, se va generando fragmentacin en el archivo, y

para resolverla probablemente se hace necesario suspender un tiempo la
ejecucin de todos los procesos que lo estn empleando (e invalidar, claro,
todas las copias en cach de los ndices). Ahora bien, para los casos de
uso en que el comportamiento predominante sea de lectura, este formato
tendr la ventaja de no desperdiciar espacio en los campos nulos o de valor
irrelevante para algunos de los registros, y de permitir la exibilidad de
registrar datos originalmente no contemplados sin tener que modicar la
estructura.
Es importante recalcar que la escritura en ambas partes de la base de
datos (ndice y datos) debe mantenerse con garantas de atomicidad 
Si se pierde la sincrona entre ellas, el resultado ser una muy probable
corrupcin de datos.

Figura 4:

Acceso relativo a ndice: Un ndice apuntando al punto justo de un

archivo sin estructura

12

2.6.

Transferencias orientadas a bloques

Un sistema de archivos es la representacin que se da a un conjunto de

archivos y directorios sobre un

dispositivo de bloques,

esto es, un dispositivo

que, para cualquier transferencia solicitada desde o hacia l, responder con un

bloque de tamao predenido.

Esto es, si bien el sistema operativo presenta una abstraccin por medio
de la cual la lectura (read()) puede ser de un tamao arbitrario, todas las
transferencias de datos desde cualquiera de los discos sern de un mltiplo del
tamao de bloques, denido por el hardware (tpicamente 512 bytes).
Al leer, como en el ejemplo anterior, slamente un registro de 75 bytes, el
sistema operativo lee el bloque completo y probablemente lo mantiene en un
cach en la memoria principal; si en vez de una lectura, la operacin efectuada
fue una de escritura (write()), y el sector a modicar no ha sido ledo an
a memoria (o fue ledo hace mucho, y puede haber sido expirado del cach),
el sistema tendr que leerlo nuevamente, modicarlo en memoria, y volver a
guardarlo a disco.

3.

Organizacin de archivos
Hasta este punto, el enfoque ha sido en qu es y cmo se maneja un archivo.

Sin embargo, no tendra sentido hablar de

sistemas de archivos

si no hubiera

una gran cantidad de archivos. Es comn que un slo medio de almacenamiento

de un equipo de uso domstico aloje

decenas de miles

de archivos, y en equipos

dedicados, no est fuera de lugar tener cientos o miles de veces tanto. Por tanto,
se tiene que ver tambin cmo organizar una gran cantidad de archivos.

3.1.

Evolucin del concepto de

directorio

El concepto dominante en almacenaimiento hoy en da es el de

jerrquicos.

directorios

Esto no siempre fue as; conviene revisar brevemente su historia

para explicar el por qu de ciertos detalles de implementacin del esquema

actualmente dominante.

3.1.1. Convenciones de nomenclatura

Cada sistema de archivos puede determinar cuntos y qu caracteres son
vlidos para designar a uno de sus elementos, y cules son separadores vlidos.
El caracter que se emplea para separar los elementos de un directorio no es un
estndar a travs de todos los sistemas operativos  Los ms comunes en uso
hoy en da son la diagonal (/), empleada en sistemas tipo Unix y derivados
(incluyendo MacOS X y Android), y la diagonal invertida (\), empleada en
CP/M y derivados, incluyendo MS-DOS y Windows.
Diversos sistemas han manejado otros caracteres (por ejemplo, el MacOS
histrico empleaba los dos puntos,

:),

y aunque muchas veces los mantenan

La seccin ?? dene los dispositivos de caracteres y /de bloques.

13

ocultos del usuario a travs de una interfaz grca rica, los programadores siempre tuvieron que manejarlos explcitamente.
A lo largo del presente texto se emplear la diagonal (/) como separador de
directorios.

3.1.2. Sistema de archivos plano

Los primeros sistemas de archivos limitaban el concepto de directorio a una
representacin plana de los archivos que lo conformaban, sin ningn concepto
de

jerarqua de directorios

como el que hoy resulta natural a los usuarios. Esto

se deba, en primer trmino, a lo limitado del espacio de almacenamiento de

las primeras computadoras en implementar esta metfora (por lo limitado del
espacio de almacenamiento, los usuarios no dejaban sus archivos a largo plazo
en el disco, sino que los tenan ah meramente mientras los requeran), y en
segundo trmino, a que no se haba an desarrollado un concepto de separacin,
permisos y privilegios como el que poco despus aparecera.
En las computadoras personales los sistemas de archivos eran tambin planos
en un primer momento, pero por otra razn: En los sistemas

profesionales

ya se

haba desarrollado el concepto; al aparecer la primer computadora personal en

1975, ya existan incluso las primeras versiones de Unix diseadas para trabajo
en red. La prioridad en los sistemas personales era mantener el cdigo del sistema
operativo simple, mnimo. Con unidades de disco capaces de manejar entre 80 y
160KB, no tena mucho sentido implementar directorios  Si un usuario quisiera
llevar a cabo una divisin temtica de su trabajo, lo colocara en distintos

exibles.

discos

El sistema operativo CP/M nunca soport jerarquas de directorios,

como tampoco lo hizo la primer versin de MS-DOS.

10

El sistema de archivos original de la Apple Macintosh, MFS, estaba construido sobre un modelo plano, pero presentando la
forma comparable a las etiquetas: Existan bajo

ilusin de directorios de una

ciertas vistas (pero notoria-

mente no en los dilogos de abrir y grabar archivos), pero el nombre de cada

uno de los archivos tena que ser nico, dado que el direcorio al que perteneca
era bsicamente slo un atributo del archivo.
Y contrario a lo que dicta la intuicin, el modelo de directorio plano no ha

almacenamiento en la nube ofrecido por el serviAmazon S3 (Simple Storage Service, Servicio Simple de Almacenamiento )
maneja nicamente objetos (comparable con nuestra denicin de archivos) y
cubetas (de cierto modo comparables con las unidades o volmenes ), y permite
referirse a un objeto o un conjunto de objetos basado en ltros sobre el total
desaparecido: El sistema de
cio

que conforman a una cubeta.

Conforme se desarrollen nuevas interfaces al programador o al usuario, probablemente se popularicen ms ofertas como la que hoy hace Amazon S3. Al da
de hoy, sin embargo, el esquema jerrquico sigue, con mucho, siendo el dominante.

10 El soporte de jerarquas de directorios fue introducido apenas en la versin 2, junto con

el soporte a discos duros de 10MB, acompaando al lanzamiento de la IBM PC modelo XT.

14

3.1.3. Directorios de profundidad ja

Las primeras implementaciones de directorios eran

de un slo nivel : El total

de archivos en un sistema poda estar dividido en directorios, fuera por tipo de

archivo (separando, por ejemplo, programas de sistema, programas de usuario y
textos del correo), por usuario (facilitando una separacin lgica de los archivos
de un usuario de pertenecientes a los dems usuarios del sistema)

El directorio raiz (base) se llama en este esquema MFD (Master File Directory, Directorio Maestro de Archivos ), y cada uno de los directorios derivados
es un UFD (User File Directory, Directorio de Archivos de Usuario ).

Figura 5:

Directorio simple, limitado a un slo nivel de profundidad

Este esquema resuelve el problema principal del nombre global nico: Antes
de los directorios, cada usuario tena que cuidar que los nombres de sus archivos
fueran nicos en el sistema, y ya teniendo cada uno su propio espacio, se volvi
una tarea mucho ms simple. La desventaja es que, si el sistema restringe a cada
usuario a escribir en su UFD, se vuelve fundamentalmente imposible trabajar
en algn proyecto conjunto: No puede haber un directorio que est tanto dentro
de

usr1 como de usr2, y los usuarios encontrarn ms dicil llevar un proyecto

conjunto.

3.1.4. Directorios estructurados en rbol

El siguiente paso natural para este esquema es permitir una jerarqua ilimitada : En vez de exigir que exista una capa de directorios, se le puede dar la vuelta
al argumento, y permitir que cada directorio pueda contener a otros archivos
o directorios a niveles arbitrarios. Esto permite que cada usuario (y que el administrador del sistema) estructure su informacin siguiendo criterios lgicos y
piense en el espacio de almacenamiento como un espacio a largo plazo.
Junto con esta estructura nacen las

rutas de bsqueda (search path ):

Tanto

los programas como las bibliotecas de sistema ahora pueden estar en cualquier
lugar del sistema de archivos. Al denirle al sistema una

ruta de bsqueda,

el

usuario operador puede desentenderse del lugar exacto en el que est determinado programa  El sistema se encargar de buscar en todos los directorios
mencionados los programas o bibliotecas que ste requiera.

11

11

La ruta de bsqueda reeja la organizacin del sistema de archivos en el contexto de la

15

Figura 6:

Directorio estucturado en rbol

3.1.5. El directorio como un grafo dirigido

Si bien parecera que muchos de los sistemas de archivos empleados hoy en
da pueden modelarse sucientemente con un rbol, donde hay un slo nodo
raiz, y donde cada uno de los nodos tiene un slo nodo padre, la semntica que
ofrecen es en realidad un

superconjunto estricto

de esta: La de un grafo dirigido.

En un grafo dirigido como el presentado en la gura 7, un mismo nodo

puede tener varios directorios

padre, permitiendo por ejemplo que un directorio

el

de trabajo comn sea parte del directorio personal de dos usuarios. Esto es,

mismo objeto

est presente en ms de un punto del rbol.

Figura 7: Directorio como un grafo dirigido acclico : El directorio proyecto est

/home/usr1 como en el directorio /home/usr2

tanto en el directorio

Un sistema de archivos puede permitir la organizacin como un

grafo dirigi-

instalacin especca. Es comn que la ruta de bsqueda de un usuario estndar en Unix sea
similar a /usr/local/bin:/usr/bin:/bin:~/bin  Esto signica que cualquier comando
que sea presentado es buscado, en el orden indicado, en los cuatro directorios presentados
(separados por el caracter :, la notacin ~ indica el directorio personal del usuario activo).
En Windows, es comn ver una ruta de bsqueda c:\WINDOWS\system32;c:\WINDOWS
16

do, aunque es comn que la interfaz que presenta al usuario12 se restrinja a un

grafo dirigido acclico : Las ligas mltiples son permitidas, siempre y cuando no
generen un ciclo.
La semntica de los sistemas Unix implementa directorios como grafos dirigidos por medio de dos mecanismos:

Liga o enlace duro

La entrada de un archivo en un directorio Unix es la

relacin entre la ruta del archivo y el

de archivos.

nmero de i-nodo

en el sistema

13 Si a partir de un archivo existente se crea una

liga dura

l, sta es sencillamente otra entrada en el directorio apuntando al mis-

i-nodo. Ambas entradas,

maestro y uno dependiente.
mo

pues, son el mismo archivo  No hay uno

En un sistema Unix, este mecanismo tiene slo dos restricciones:

1. Slo se pueden hacer ligas duras dentro del mismo volumen.
2. No pueden hacerse ligas duras a directorios, slo a archivos.

Liga o enlace simblico

Es un archivo

especial,

14

que meramente indica a

dnde apunta. El encargado de seguir este archivo a su destino (esto es,

de

resolver

la liga simblica) es el sistema operativo mismo; un proceso

no tiene que hacer nada especial para seguir la liga.

Una liga simblica puede

apuntar

a directorios, incluso creando ciclos, o

a archivos en otros volmenes.

Cuando se crea una liga simblica, la liga y el archivo son dos entidades
distintas. Si bien cualquier proceso que abra al archivo destino estar trabajando con la misma entidad, en caso de que ste sea renombrado o
eliminado, la liga quedar

rota

(esto es, apuntar a una ubicacin inexis-

tente).
Si bien estos dos tipos de liga existen tambin en los sistemas Windows
en dichos sistemas sigue siendo ms comn emplear los
denomina as a un archivo (identicado por su extensin,
creado para poder

apuntar

accesos directos.

15 ,
Se

.lnk), principalmente

a los archivos desde el escritorio y los menes  Si

un proceso solicita al sistema abrir el

acceso directo,

no obtendr al archivo

destino, sino que al acceso directo mismo.

Ahora, si bien tanto las ligas duras como las ligas simblicas existen tambin
en Windows, su uso es muy poco frecuente. El API de Win32 ofrece las funciones
necesarias, pero stas no estn reejadas desde la interfaz usuario del sistema 
Y son sistemas donde el usuario promedio no emplea una interfaz programador,

Esta simplicacin es simplemente una abstraccin, y contiene una pequea mentira, que
ser13 desmentida en breve.
El signicado y la estructura de un i-nodo se abordan en el captulo ??.
14 Formalmente, puede haberlas, pero slo el administrador puede crearlas; en la seccin
3.2.1
se cubre la razn de esta restriccin al hablar de recorrer los directorios.
15 nicamente en aquellos que emplean el sistema de archivos NTFS, no en los que utilizan
alguna de las variantes de FAT
12

17

sino que una interfaz grca. Las ligas, pues, no son ms empleadas por

cultural :

cuestin

En sus comunidades de usuarios, nunca fueron frecuentes, por lo cual

se mantienen como conceptos empleados slo por los

usuarios avanzados.

Ya con el conocimiento de las ligas, y reelaborando la gura 7 con mayor

apego a la realidad: En los sistemas operativos (tanto Unix como Windows), todo
directorio tiene dos entradas especiales: Los directorios

. y .., que aparecen tan

pronto como el directorio es creado, y resultan fundamentales para mantener la

navegabilidad

Figura 8:

del rbol.

Directorio como un

directorio actual

grafo dirigido,
padre ..

mostrando los

enlaces ocultos

al

y al directorio

Como se puede ver en la gura 8, en todos los directorios,

al mismo directorio, y

..

es una liga al directorio

padre

. es una liga dura

(de nivel jerrquico

inmediatamente superior). Claro est, como slo puede haber una liga

..,

un

directorio enlazado desde dos lugares distintos slo apunta hacia uno de ellos con
su enlace
torio

..; en este caso, el directorio comn proyecto est dentro del direc/home/usr2. La gura representa la liga simblica desde /home/usr1

como una lnea punteada.

Hay una excepcin a esta regla: El directorio raiz. En este caso, tanto

..

. como

apuntan al mismo directorio.

Esta es la razn por la cual no se puede tomar rigurosamente a un rbol de

archivos como a un
entradas
entradas

3.2.

grafo dirigido acclico, ni en Windows ni en Unix: Tanto las

. (al apuntar al mismo directorio donde

.. (al apuntar al directorio padre) crean

estn contentidas) como las

ciclos.

Operaciones con directorios

Al igual que los archivos, los directorios tienen una semntica bsica de
acceso. Los directorios resultan tambin tipos de datos abstractos con algunas
operaciones denidas. Muchas de las operaciones que pueden realizarse con los

18

directorios son anlogas a las empleadas para los archivos.

16 Las operaciones

bsicas a presentar son:

Abrir y cerrar

Al igual que los archivos, los directorios deben ser

para trabajar con ellos, y

cerrados

esto, en C, se emplean las funciones

funciones trabajan asociadas a un

abiertos

cuando ya no se les requiera. Para

opendir()

closedir().

Estas

ujo de directorio (directory stream ),

que funciona de forma anloga a un descriptor de archivo.

Listado de archivos
el directorio se
funcin

Para mostrar los archivos que conforman a un directorio,

abre

(tal como se hara con un archivo, pero empleando la

opendir()

en vez de

open()),

y va

leyendo

(con

readdir())

cada una de sus entradas. Cada uno de los resultados es una estrcutura

dirent (directory entry, esto es, entrada de directorio ), que contiene su

d_name, un apuntador a su i-nodo en d_ino, y algunos datos

nombre en

adicionales del arcihvo en cuestin.

Para presentar al usuario la lista de archivos que conforman un directorio,
podra hacerse:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#include <stdio.h>
#include <dirent.h>
#include <sys/types.h>
int main(int argc, char *argv[]) {
struct dirent *archivo;
DIR *dir;
if (argc != 2) {
printf("Indique el directorio a mostrar\n");
return 1;
}
dir = opendir(argv[1]);
while ((archivo = readdir(dir)) != 0) {
printf(" %s\t", archivo->d_name);
}
printf("\n");
closedir(dir);
}
Al igual que en al hablar de archivos se puede
descriptor de archivo, para
pio del listado se emplea

Buscar un elemento

rebobinar

reposicionar (seek())

al

el descriptor del directorio al princi-

rewinddir().

Si bien en el transcurso del uso del sistema operativo re-

sulta una operacin frecuente que el usuario solicite el listado de archivos

dentro de un directorio, resulta mucho ms frecuente buscar a un archivo

De hecho, en muchos sistemas de archivos los directorios son meramente archivos de tipo
especial, que son presentados al usuario de forma distinta. En la seccin ?? se presenta un
ejemplo.
16

19

en particular. La llamada

fopen()

antes descrita efecta una bsque-

da similar a la presentada en el ejemplo de cdigo anterior, claro est,

detenindose cuando encuentra al archivo en cuestin.

Crear, eliminar o renombrar un elemento

Si bien estas operaciones se ll-

evan a cabo sobre el directorio, son invocadas a travs de la semntica

orientada a archivos: Un archivo es creado con

remove(),

y renombrado con

fopen(),

eliminado con

rename().

3.2.1. Recorriendo los directorios

Es frecuente tener que aplicar una operacin a todos los archivos dentro de
cierto directorio  Por ejemplo, para agrupar a un directorio completo en un
archivo comprimido, o para copiar todos sus contenidos a otro medio. Procesar
todas las entradas de un directorio, incluyendo las de sus subdirectorios, se
denomina

recorrer el directorio

(en ingls,

directory traversal ).

Si se trabaja sobre un sistema de archivos plano, la operacin de recorrido

completo puede realizarse con un programa tan simple como el presentado en
la seccin anterior.
Al hablar de un sistema de profundidad ja, e incluso de un directorio estructurado en rbol, la lgica se complica levemente, dado que para recorrer el
directorio es necesario revisar, entrada por entrada, si esta es a su vez un directorio (y en caso de que as sea, entrar y procesar a cada uno de sus elementos).
Hasta aqu, sin embargo, se puede recorrer el directorio sin requerir de mantener
estructuras adicionales en memoria representando el estado.
Sin embargo, al considerar a los grafos dirigidos, se vuelve indispensable
mantener en memoria la informacin de todos los nodos que ya han sido tocados
 en caso contrario, al encontrar ciclo (incluso si este es creado por mecanismos
como las

ligas simblicas ), se corre el peligro de entrar en un bucle innito.

./img/dot/dir_traversal.png
Para recorrer al directorio ilustrado como ejemplo en la gura

??, no bastara

tomar nota de las rutas de los archivos conforme son recorridas  Cada vez que
los sean procesados, su ruta ser distinta. Al intentar respaldar al directorio

/home/jose/proyecto,

por ejemplo, el recorrido resultante podra ser:

/home/jose/proyecto
/home/jose/proyecto/miembros
/home/jose/proyecto/miembros/jose
/home/jose/proyecto/miembros/jose/proyectos
/home/jose/proyecto/miembros/jose/proyectos/miembros
. . . Y un etctera innito.

20

Para resolver esta situacin, los programas que recorren directorios en los
sistemas de archivos

reales

deben emplear un indexado basado en

i-nodo 17 iden-

tica sin lugar a dudas a cada uno de los archivos. En el caso presentado, si el
i-nodo de

jose

fuera 10543, al consultar a los miembros de

miembros

el sis-

tema encontrar que su primer entrada apunta al i-nodo 10543, por lo cual la
registrara slo como un apuntador a datos

ya archivados,

segunda entrada del directorio, que apunta a

y continuara con la

pedro.

3.2.2. Otros esquemas de organizacin

Por ms que el uso de sistemas de archivos basados en directorios jerrquicos
parece universal y es muy ampliamente aceptado, hay cada vez ms casos de uso
que apuntan a que se pueda estar por dar la bienvenida a una nueva metfora
de organizacin de archivos.
Hay distintas propuestas, y claro est, es imposible an saber cul direccin
obtendr el favor del mercado  O, dado que no necesariamente siga existiendo
un modelo apto para todos los usos, de

3.3.

qu

segmento del mercado.

Montaje de directorios

Para trabajar con el contenido de un sistema de archivos, el sistema operativo

tiene que

montarlo :

Ubicarlo en algn punto del rbol de archivos visible al

sistema y al usuario.
Es muy comn, especialmente en los entornos derivados de Unix, que un
sistema operativo trabaje con distintos sistemas de archivos al mismo tiempo.
Esto puede obedecer a varias causas, entre las cuales se encuentran:

Distintos medios fsicos

Si la computadora tiene ms de una unidad de al-

macenamiento, el espacio dentro de cada uno de los discos se maneja como

un sistema de archivos indepentiente. Esto es especialmente cierto en la
presencia de unidades removibles (CDs, unidades USB, discos duros externos, etc.)

Diferentes usos esperados

Como se ver ms adelante, distintos esquemas

de organizacin (esto es, distintos sistemas de archivos) presentan ventajas
para distintos patrones de uso. Por ejemplo, tiene sentido que una base
de datos resida sobre una organizacin distinta a la de los programas
ejecutables (binarios) del sistema.

Abstracciones de sistemas no-fsicos

diversas estructuras

El sistema operativo puede presentar

con una estructura

de sistema de archivos. El ejemplo

ms claro de esto es el sistema de archivos virtual

/proc,

existente en

los sistemas Unix, que permite ver diversos aspectos de los procesos en
ejecucin (y, en Linux, del sistema en general). Los archivos bajo

/proc

17 Que si bien no ha sido denido an formalmente, para esta discusin bastar saber que
es un nmeo nico por volumen.

21

no existen en ningn disco, pero se presentan como si fueran archivos

estndar.

Razones administrativas

El administrador del sistema puede emplear sis-

temas de archivos distintos para aislar espacios de usuarios entre s: Por

ejemplo, para evitar que un exceso de mensajes enviados en la bitcora
(tpicamente bajo

/var/log)

saturen al sistema de archivos principal, o

para determinar patrones de uso mximo por grupos de usuarios.

En los sistemas tipo Unix, el mecanismo para montar los archivos es el de
un rbol con

puntos de montaje.

sistema operativo

montar

todos los archivos y directorios del

un nico rbol. Cuando se solicita al

Esto es,

sistema operativo estn estructurados en

un sistema de archivos en determinado lugar, ste se

integra al rbol, ocultando todo lo que el directorio en cuestin previamente

18

tuviera.

Figura 9: rbol formado del montaje de sda1 en la raiz, sda2 como /usr, sdb1
/home, y el directorio virtual proc

como

La manera en que esto se presenta en sistemas Windows es muy distinta.

Ah, cada uno de los volumenes

detectados

recibe un

identicador de volumen,

y es montado automticamente en un sistema de directorio estructurado como

19 Este rbol

rbol de un slo nivel representando a los dispositivos del sistema.

es presentado a travs de la interfaz grca (aunque este nombre no signica

Mi PC.
ruta completa a determinado

nada para el API del sistema) como

Para especicar la

archivo, se inicia con el

identicador del volumen. De este modo, la especicacin absoluta de un archivo

es una cadena como

VOL:\Dir1\Dir2\Archivo.ext  El caracter : separa

\ separa uno de otro a

al volumen del rbol del sistema de archivos, y el caracter

los directorios. Por convencin, si no se especica la unidad, el sistema asumir

18 Hay implementaciones que exigen que el montaje se realice exclusivamente en directorios

vacos; existen otras, como UnionFS, que buscan seguir presentando una interfaz de lectura
a los objetos que existan en el directorio previo al montaje, pero realizan las escrituras nicamente en el sistema ya montado; estas complican fuertemente algunos aspectos semnticos,
por19 lo cual resultan poco comunes.
En realidad, este rbol no slo incluye a los volmenes de almacenamiento, sino que a
los dems dispositivos del sistema, como los distintos puertos, pero los oculta de la interfaz
grca.
22

que se est haciendo referencia a la

unidad actual

(a grandes rasgos, la ltima

unidad en ser utilizada).

Los identicadores de volumen estn preasignados, muchos de ellos segn a
un esquema heredado desde la poca de las primeras PC: Los volmenes

AyB
C se reere al disco duro de
detectando el sistema son D, E, F,

estn reservados para las unidades de disco exible;

arranque, y las unidades posteriores que va
etc.

Es posible modicar esta nomenclatura y congurar a los discos para estar en

otra ubicacin, pero muchas aplicaciones dependen ya de este comportamiento
y conguracin especca.

Figura 10:

4.

Vista de un sistema de archivos Windows

Sistemas de archivos remotos

Uno de los principales y primeros usos que se dio a la comunicacin en red fue

el de compartir archivos entre computadoras independientes. En un principio,

esto se realizaba de forma

explcita,

con transferencias manuales a travs de

programas dedicados a ello, como sera hoy en da el FTP.

Por otro lado, desde mediados de los 1980, es posible realizar estas transferencias de forma

la red

implcita

automtica, empleando sistemas de archivos sobre

sistemas de archivos remotos ). stos se presende la abstraccin de sistemas no-fsicos que fueron

(o lo que es lo mismo,

tan como caso particular

23

mencionados en la seccin anterior: Si bien el sistema operativo no tiene acceso

directo

a los archivos y directorios que le solicitar el usuario, a travs de los

mdulos de red, sabe cmo obtenerlos y presentarlos

como si fueran locales.

Al hablar de sistemas de archivos en red, casi siempre se har siguiendo un

modelo cliente-servidor. Estos trminos no se reeren a las prestaciones relativas

dentro de cada conexin 
Esto es, se designa como cliente a la computadora que solicita un servicio, y
como servidor a la que lo provee; es frecuente que dos computadoras sean tanto
de una computadora, sino al rol que sta juega

servidor como cliente la una de la otra en distintos servicios.

4.1.
El

Network File System (NFS)

Sistema de Archivos en Red (Network File System, mejor conocido por

NFS ) fue creado por Sun Microsystems, y desde 1984 forma parte

sus siglas,

de su sistema operativo  Result una implementacin tan exitosa que a los

pocos aos formaba parte de todos los sistemas tipo Unix.
NFS est construido sobre el mecanismo

mada a Procedimientos Remotos ),

RPC (Remote Procedure Call, Lla-

un mecanismo de mensajes y manejo bsico

de sesin que acta como una capa superior a TCP/IP, incluyendo facilidades

descubrimiento de recursos y abstraccin. RPC puede ser comparado con

DCE/RPC de OSF, DCOM de Microsoft, y hoy en da, SOAP
y XML-RPC. Estos mecanismos permiten al programador delegar en un servicio el manejo de las conexiones de red, particularmente (en el caso particular

de

protocolos como

aqu descrito) la persistencia de sesiones en caso de desconexin, y limitar su

atencin a una

conexin virtual establecida.

La motivacin de origen para la creacin de NFS fue presentar una solucin

que aprovechara el hardware existente y centralizara la administracin: Ofrecer
las facilidades para contar con redes donde hubiera un

servidor de archivos,

donde las estaciones de trabajo tuvieran nicamente una instalacin bsica,

20

y el entorno de usuario completo estuviera disponible en cualquiera de las estaciones.

NFS ofrece sobre la red un sistema de archivos con la semntica Unix comple-

21 y usarlo como si fuera

ta  Para montar un sistema remoto, basta montarlo

local. El manejo de permisos, usuarios, e incluso las ligas duras y simblicas se

manejan exactamente como se hara localmente.
NFS es un protocolo muy ligero  No implementa cifrado ni vericaciones
adicionales, pero al da de hoy, es uno de los mejores mecanismos para el envo de grandes cantidades de informacin  Pero siempre en redes que sean

completamente conables.

20 Incluso manejando estaciones de trabajo diskless, esto es, computadoras sin disco duro,
cuyo sistema de arranque tiene la capacidad de solicitar al servidor le enve incluso el ncleo
del21sistema operativo que ejecutar
Para montar un sistema remoto, se emplea un comando como mount
archivos.unam.mx:/ext/home /home, con lo cual el directorio /ext/home ubicado
en el servidor archivos.unam.mx aparecer montado como directorio /home local.

24

Ahora, NFS se presenta como uno de los componentes de una solucin com-

consistente en todos los clientes; Sun ofreca tambin un esquema llamado Yellow
Pages (posteriormente renombrado a NIS, Network Information System ) para

pleta. Dado que se espera que la informacin de usuarios y permisos sea

compartir la informacin de autenticacin y listas de usuarios.

La desventaja, en entornos sin NIS, es que los permisos se manejan segn
el ID numrico del usuario. Si en diferentes sistemas el mismo usuario tiene
diferentes IDs, los permisos no coincidirn. Es ms, dado que el control de
acceso principal es nicamente por direccin IP, para tener acceso irrestricto
a los archivos de otros usuarios en NFS basta con tener control pleno de una
computadora cualquiera en la red para poder

asumir o usurpar la identidad

de

cualquier otro usuario.

Por ltimo, para garantizar que las escrituras a archivos se llevaran a cabo
cuando eran solicitadas (en contraposicin a asumir xito y continuar), todas las
escrituras en un principio sobre NFS eran manejadas de forma

sncrona, esto es,

tras grabar un archivo, el cliente no continuaba con la ejecucin hasta no tener

conrmacin por parte del servidor de que los datos estaban ya guardados en
disco. Esto, si bien asegura que el usuario recibir retroalimentacin conable
respecto a la operacin que realiz, ocasiona demoras que muchas veces son
percibidas como excesivas.
Versiones posteriores del protocolo mejoraron sobre los puntos dbiles aqu
mencionados. Al da de hoy, casi 30 aos despus de su presentacin, NFS es
an un sistema de archivos en red muy ampliamente empleado.

4.2.

Common Internet File System (CIFS)

El equivalente a NFS en los entornos donde predominan los sistemas Windows es el protocolo CIFS (

Common Internet File System, Sistema de Archivos

Comn para Internet). Aparece en los sistemas primarios de Microsoft alrededor

22 , originalmente bajo el nombre SMB (Server

de 1990

de Mensaje del Servidor ).

Message Block, Bloque

Las primeras implementaciones estaban basadas en el protocolo

cuentemente conocido como

NetBEUI,

NBF,

fre-

un protocolo no ruteable diseado para

redes pequeas y entornos sencillos de ocina. A partir de Windows 2000 se ha

reimplementado completamente para operar sobre TCP/IP. Es a partir de este
momento que se le comienza a denominar
siendo ampliamente utilizado.

23

CIFS,

aunque el nombre

SMB

sigue

CIFS se ajusta mucho ms a la semntica de los sistemas MS-DOS y Windows, aunque dado el lapso de tiempo que ha existido, ha pasado por varios
cambios fundamentales, que al da de hoy complican su uso.
Para tener acceso a un volumen compartido por SMB se introdujo el coman-

do

NET;24

basta indicar a DOS o Windows (desde la lnea de comando)

NET

El desarrollo de SMB naci como LAN Manager, originalmente para OS/2

Es debido a este nombre que la implementacin de CIFS para sistemas Unix, Samba, fue
llamado
de esta manera.
24 Este comando es empleado en MS-DOS, pero est tambin disponible en Windows, y al
22
23

25

USE W: \\servidor\directorio para que el recurso compartido bajo el

nombre directorio dentro del equipo conocido como servidor aparezca en
el rbol

Mi PC,

y el usuario pueda emplear sus contenidos como si fuera un

sistema de archivos local, con un volumen asignado de

W:.

Cuando LAN Manager fue introducido al mercado, los sistemas Microsoft no

manejaban an el concepto de usuarios, por lo que la nica medida de seguridad
que implementaba SMB era el manejo de hasta dos contraseas por directorio
compartido: Con una, el usuario obtena acceso de slo lectura, y con la otra, de
lectura y escritura. Tras la aparicin de Windows NT, se agreg un esquema de
identicacin por usuaro/contrasea, que posibilita el otorgamiento de permisos
con una

granularidad

25

mucho menor.

SMB fue pensado originalmente para una red

pequea, con hasta un par de

decenas de equipos. La mayor parte de los paquetes eran enviados en modo

de difusin (broadcast ),

por lo que era fcil llegar a la saturacin, y no exista

un esquema centralizado de resolucin de nombres, con lo que era frecuente

encontrar

no

a determinado equipo.

Los cambios que CIFS presenta a lo largo de los aos son muy profundos.
Las primeras implementaciones presentan fuertes problemas de conabilidad,
rendimiento y seguridad, adems de estar planteadas para su uso en un slo tipo de sistema operativo; al da de hoy, estos puntos han todos mejorado
fuertemente. En sistemas Unix, la principal implementacin,

Samba,

fue crea-

da haciendo ingeniera inversa sobre el protocolo; a lo largo de los aos, se ha

convertido en un esquema tan robusto que es hoy por hoy tomado como implementacin refrencia.

4.3.

Sistemas de archivos distribudos: Andrew File System (AFS)

Los dos ejemplos de sistema de archivos en red presentados hasta ahora

comparten una visin

tradicional

del modelo cliente-servidor: Al ver el comando

que inicializa una conexin, e incluso a ver la informacin que guarda el ncleo
del cliente respecto a cualquiera de los archivos, resulta claro cul es el servidor
para cada uno de ellos.

Andrew File System, desarrolaldo en la Carnegie Mellon University26 y publicado en 1989, plantea presentar un verdadero sistema de archivos distribudo, en
el cual los recursos compartidos no tengan que estar en un servidor en particular,
sino que un conjunto de equipos se repartan la carga (esto es, agnosticismo a la
ubicacin ). AFS busca tambin una fcil escalabilidad, la capacidad de agregar
tanto espacio de almacenamiento como equipos con rol de servidor. AFS permite
inclusive migrar completamente un volumen mientras est siendo empleado, de
forma transparente.

da25de hoy es una de las principales herramientas para administrar usuarios.

Esto signica, que puede controlarse el acceso permitido ms namente, a nivel archivo
individual
y usuario individual.
26 Como parte del Proyecto Andrew, denominado as por el nombre de los fundadores de
esta universidad: Andrew Carnegie y Andrew Mellon
26

Ante la complejidad e inestabilidad adicional que presentan con tanta fre-

27 (y lo hacan mucho ms hace 30 aos): AFS debe

cuencia las redes grandes

operar tan conablemente como sea posible,

opera correctamente.

incluso sin la certeza de que la red

AFS construye fuertemente sobre el modelo de tickets y credenciales de Kerberos,28 pero se aleja sensiblemente de la semntica de operacin de archivos que
hasta ahora se han presentado. Muchos eventos, operaciones y estados van lig-

momento en el tiempo en que se presentan, a travs de un modelo de

consistencia dbil (weak consistency model ). Muy a grandes rasgos, esto signica
ados al
que:
Cuando se abre un archivo, ste se copia completo al cliente. Todas las
lecturas

y escrituras

(a diferencia de los esquemas tradicionales, en que

stas son enviadas al servidor

lo antes posible

y de forma sncrona) se

dirigen nicamente a la copia local.

servidor de origen, el cual se

compromete a noticar a los clientes si un archivo abierto fue modicado
(esto es, a hacer una llamada o callback ). Los clientes pueden entonces

Al cerrar el archivo, ste se copia de vuelta al

intentar incorporar los cambios a su versin de trabajo, o continuar con

la copia ya obtenida  Es

esperable

que si un segundo cliente realiza

alguna modicacin, incorpore los cambios hechos por el primero, pero

esta responsabilidad se deja a la implementacin del programa en cuestin.
Esto signica en pocas palabras que los cambios a un archivo abierto por
un usuario no son visibles a los dems de inmediato; slo una vez que se cierra
un archivo, los cambios hechos a ste son puestos a disposicin de las sesiones
abiertas actuales, y slo son enviados como

versin actual

a las sesiones abiertas

posteriormente.
Con este cambio semntico, debe quedar claro que AFS no busca ser un sistema para todo uso ni un reemplazo universal de los sistemas de archivos locales,
en contraposicin de los sistemas de archivos centralizados. AFS no plantea en
ningn momento una operacin

diskless. Bajo el esquema aqu descrito, las lec-

turas y escrituras resultan baratas, porque se realizan exclusivamente sobre el

cach local, pero abrir y cerrar un archivo puede ser muy caro, porque debe
transferirse el archivo completo.
Hay aplicaciones que verdaderamente sufriran si tuvieran que implementarse sobre un sistema de archivos distribudo  Por ejemplo, si una base de
datos se distribuyera sobre AFS, la carencia de mecanismos de bloqueo sobre

secciones

del archivo, y el requisito de operar sobre

archivos completos

impracticable compartir un archivo de uso intensivo y aleatorio.

haran

El uso tpico de AFS se planteaba para organizaciones grandes, del orden de decenas de
miles
de estaciones
28 Un sistema de autenticacin y autorizacin centralizado para entornos corporativos.
27

27

5.

Otros recursos

File System Interface: Functions for manipulating les

https://www.gnu.org/software/libc/manual/html_node/File-System-Interface.
html
The GNU C Library manual (Free Software Foundation)

Disks from the Perspective of a File System

http://queue.acm.org/detail.cfm?id=2367378
Marshall Kirk McKusick (2012); ACM Queue

Traduccin al espaol:

de archivos

Los discos desde la perspectiva de un sistema

http://cyanezfdz.me/post/los-discos-desde-la-perspectiva-de-un-sistema-de-archiv
Csar Yez (2013).

File-system development with stackable layers

https://dl.acm.org/citation.cfm?id=174613.174616
Heidemann y Popek (1994); ACM Transactions on Computer Systems

Serverless network le systems

https://dl.acm.org/citation.cfm?doid=225535.225537
Thomas E. Anderson et. al. (1996); ACM Transactions on Computer Systems

OpenPlanets Results Evaluation Framework

http://data.openplanetsfoundation.org/ref/
David Tarrant (2012). Muestra la evolucin a lo largo de los aos de cmo
reconocen archivos de tipos conocidos varias herramientas

Finding open les with lsof

http://www.ibm.com/developerworks/aix/library/au-lsof.html)
Sean A. Walberg (2006); IBM DeveloperWorks

28