Un bloque de control de archivos ( FCB ) es una estructura del sistema de archivos en la que se mantiene el estado de un archivo abierto . El FCB es administrado por el sistema operativo, pero reside en la memoria del programa que utiliza el archivo, no en la memoria del sistema operativo. Esto permite que un proceso tenga tantos archivos abiertos a la vez como desee, siempre que pueda reservar suficiente memoria para un FCB por archivo.
El FCB tiene su origen en CP/M y también está presente en la mayoría de las variantes de DOS , aunque sólo como medida de compatibilidad con versiones anteriores de MS-DOS 2.0 y posteriores. Un FCB completo tiene una longitud de 36 bytes; en las primeras versiones de CP/M, era de 33 bytes. Este tamaño fijo, que no se podía aumentar sin romper la compatibilidad de las aplicaciones, llevó a la desaparición del FCB como método estándar para acceder a los archivos.
Los significados de varios de los campos del FCB difieren entre CP/M y DOS, y también según la operación que se esté realizando. Los siguientes campos tienen significados consistentes: [1]
El campo de 20 bytes que comienza en el desplazamiento 0x0C contenía campos que (entre otros) proporcionaban más información sobre el archivo: [2]
Las versiones más nuevas del DOS utilizaron valores adicionales hasta que la nueva información ya no cabía en esos 20 bytes. Algunos bytes de "desplazamiento negativo" anteriores se extrajeron de los espacios reservados en la página cero de CP/M y el prefijo de segmento de programa del DOS para almacenar atributos de archivo. [1]
En CP/M, 86-DOS y PC DOS 1.x/MS-DOS 1.xx, el FCB era el único método para acceder a los archivos. Bajo DOS, unas pocas subfunciones INT 21h proporcionaban la interfaz para operar en archivos utilizando el FCB. [1] [3] [4] Cuando, con MS-DOS 2, se hicieron preparativos para soportar múltiples procesos o usuarios, [3] [4] usar otros sistemas de archivos [3] [4] que FAT o para compartir archivos [4] a través de redes en el futuro, se consideró que los FCB eran demasiado pequeños para manejar los datos adicionales requeridos para tales características [4] y, por lo tanto, se consideraron inadecuados para varias rutas de expansión futuras. [3] Además, no proporcionaban un campo para especificar subdirectorios. [3] Exponer datos relacionados con el sistema de archivos al espacio de usuario también se consideró un riesgo de seguridad. [4] Por lo tanto, los FCB fueron reemplazados por los manejadores de archivos , como se usa en UNIX y sus derivados. [3] Los identificadores de archivos son simplemente números enteros consecutivos asociados con archivos abiertos específicos.
Si un programa utiliza la nueva API de manejo de archivos para abrir un archivo, el sistema operativo gestionará su estructura de datos interna asociada a ese archivo en su propia área de memoria. Esto tiene la gran ventaja de que estas estructuras pueden aumentar de tamaño en versiones posteriores del sistema operativo sin romper la compatibilidad con los programas de aplicación; su desventaja es que, dada la gestión de memoria bastante simplista de DOS, el espacio para tantas de estas estructuras como sea probable que utilice el programa más "ávido de archivos" debe reservarse en el momento del arranque y no puede utilizarse para ningún otro propósito mientras el equipo esté en funcionamiento. Dicha reserva de memoria se realiza utilizando la directiva FILES = en el archivo CONFIG.SYS . Este problema no ocurre con los FCB en DOS 1 o en CP/M, ya que el sistema operativo almacena todo lo que necesita saber sobre un archivo abierto dentro del FCB y, por lo tanto, no necesita utilizar ninguna memoria por archivo en el espacio de memoria del sistema operativo. Al utilizar FCB en MS-DOS 3 o posterior, el formato de FCB depende de si SHARE.EXE está cargado y de si el FCB hace referencia a un archivo local o remoto y, a menudo, hace referencia a una entrada SFT. Debido a esto, el número de FCB que se pueden mantener abiertos a la vez en DOS 3 o posterior también está limitado, normalmente a 4; utilizando la directiva FCBS = en el archivo CONFIG.SYS, se puede aumentar más allá de ese número si es necesario. En DR-DOS , tanto FILES como FCBS provienen del mismo grupo interno de estructuras de identificadores disponibles y se asignan dinámicamente según sea necesario. [5]
Los FCB fueron compatibles con todas las versiones de MS-DOS y Windows hasta la introducción del sistema de archivos FAT32 . Windows 95 , Windows 98 y Windows Me no admiten el uso de FCB en unidades FAT32 debido a sus números de clúster de 32 bits, [4] excepto para leer la etiqueta del volumen. Esto provocó que algunas aplicaciones DOS antiguas, incluido WordStar , fallaran en estas versiones de Windows.
La interfaz FCB tampoco funciona correctamente en Windows NT , 2000 , etc. WordStar no funciona correctamente en estos sistemas operativos. Los emuladores DOS DOSEMU y DOSBox implementan la interfaz FCB correctamente, por lo que son una forma de ejecutar programas DOS más antiguos que necesitan FCB en sistemas operativos modernos.
Una estructura de datos complementaria utilizada junto con el FCB era el Área de Transferencia de Disco (DTA). [2] Este es el nombre que se le daba al búfer en el que se leían o escribían los contenidos de los archivos (registros). Las funciones de acceso a archivos en DOS que utilizaban el FCB asumían una ubicación fija para el DTA, que inicialmente apuntaba a una parte del PSP (ver la siguiente sección); esta ubicación se podía cambiar llamando a una función DOS, y los accesos a archivos posteriores utilizaban implícitamente la nueva ubicación.
Con la desuso del método FCB, las nuevas funciones de acceso a archivos que usaban identificadores de archivos también proporcionaron un medio para especificar un búfer de memoria para el contenido de archivos con cada llamada de función, de modo que mantener búferes simultáneos e independientes (ya sea para archivos diferentes o para el mismo archivo) se volvió mucho más práctico.
Cada ejecutable DOS iniciado desde el shell ( COMMAND.COM ) contaba con una estructura de datos precargada de 256 bytes llamada Prefijo de Segmento de Programa (PSP). Los campos relevantes dentro de esta estructura incluyen: [2]
Esta estructura de datos se podía encontrar al principio del segmento de datos cuya dirección fue proporcionada por DOS al inicio del programa en los registros de segmento DS y ES. Además de proporcionar la línea de comandos del programa textualmente en la dirección 0x81, DOS también intentó construir dos FCB correspondientes a las dos primeras palabras en la línea de comandos, con el propósito de ahorrarle trabajo al programador en el caso común en que estas palabras fueran nombres de archivos sobre los que operar. Dado que estos FCB permanecían sin abrir, no se produciría ningún problema incluso si estas palabras de la línea de comandos no se referían a archivos.
La dirección inicial del DTA se estableció para superponer el área en el PSP (en la dirección 0x80) donde se almacenaban los argumentos de la línea de comandos, de modo que un programa necesitaba analizar esta área en busca de argumentos de la línea de comandos antes de invocar funciones DOS que hicieran uso del DTA (como leer un registro de archivo), a menos que el programa tuviera cuidado de cambiar la dirección del DTA a alguna otra región de memoria (o no usar las funciones DTA/FCB en absoluto, que pronto quedaron obsoletas en favor de los controladores de archivos).
{{cite book}}: |work=ignorado ( ayuda ) (NB. NWDOSTIP.TXT es un trabajo exhaustivo sobre Novell DOS 7 y OpenDOS 7.01 , que incluye la descripción de muchas características y componentes internos no documentados. Es parte de la colección MPDOSTIP.ZIP aún más grande del autor, mantenida hasta 2001 y distribuida en muchos sitios en ese momento. El enlace provisto apunta a una versión anterior convertida a HTML del archivo NWDOSTIP.TXT).