Una API de sistema de archivos es una interfaz de programación de aplicaciones a través de la cual una utilidad o un programa de usuario solicita servicios de un sistema de archivos. Un sistema operativo puede proporcionar abstracciones para acceder a diferentes sistemas de archivos de forma transparente.
Algunas API de sistemas de archivos también pueden incluir interfaces para operaciones de mantenimiento, como la creación o inicialización de un sistema de archivos, la verificación de la integridad del sistema de archivos y la desfragmentación .
Cada sistema operativo incluye las API necesarias para los sistemas de archivos que admite. Microsoft Windows tiene API de sistemas de archivos para NTFS y varios sistemas de archivos FAT . Los sistemas Linux pueden incluir API para ext2 , ext3 , ReiserFS y Btrfs , por nombrar algunos.
Algunos de los primeros sistemas operativos eran capaces de manejar únicamente sistemas de archivos en cinta y disco . Estos proporcionaban las interfaces más básicas con:
Para lograr una mayor coordinación, como la asignación y desasignación de dispositivos, fue necesario agregar lo siguiente:
A medida que los sistemas de archivos proporcionaron más servicios, se definieron más interfaces:
A medida que aumentaron los tipos de sistemas de archivos, la estructura jerárquica y los medios admitidos, las características adicionales necesitaron algunas funciones especializadas:
Los sistemas multiusuario requieren API para:
La escritura de datos de usuario en un sistema de archivos está prevista para su uso directo por parte del programa de usuario o de la biblioteca de tiempo de ejecución. La biblioteca de tiempo de ejecución de algunos lenguajes de programación puede proporcionar conversión de tipos, formateo y bloqueo. Algunos sistemas de archivos proporcionan identificación de registros por clave y pueden incluir la reescritura de un registro existente. Esta operación a veces se denomina PUT o PUTX(si el registro existe)
La lectura de datos de usuario, a veces llamada GET, puede incluir una dirección (hacia adelante o hacia atrás) o, en el caso de un sistema de archivos con clave, una clave específica. Al igual que con la escritura, las bibliotecas en tiempo de ejecución pueden interceder por el programa de usuario.
El posicionamiento incluye el ajuste de la ubicación del siguiente registro. Esto puede incluir avanzar o retroceder, así como posicionarse al principio o al final del archivo.
La API abierta puede solicitarse explícitamente o invocarse implícitamente al emitirse la primera operación de un proceso sobre un objeto. Puede provocar el montaje de medios extraíbles, el establecimiento de una conexión con otro host y la validación de la ubicación y la accesibilidad del objeto. Actualiza las estructuras del sistema para indicar que el objeto está en uso.
Los requisitos habituales para solicitar acceso a un objeto del sistema de archivos incluyen:
Puede ser necesaria información adicional, por ejemplo:
Estos se solicitan a través de una biblioteca de lenguaje de programación que puede proporcionar coordinación entre los módulos en el proceso, además de reenviar la solicitud al sistema de archivos.
Es de esperar que algo pueda salir mal durante el procesamiento de la apertura.
Dependiendo del lenguaje de programación, las especificaciones adicionales en el lenguaje abierto pueden establecer los módulos para manejar estas condiciones. Algunas bibliotecas especifican un módulo de biblioteca para el sistema de archivos que permite el análisis en caso de que el programa que se está ejecutando no pueda realizar ninguna acción significativa como resultado de un fallo. Por ejemplo, si el fallo se produce al intentar abrir el archivo de entrada necesario, la única acción puede ser informar del fallo y abortar el programa. Algunos lenguajes simplemente devuelven un código que indica el tipo de fallo que siempre debe comprobar el programa, que decide qué informar y si puede continuar.
El cierre puede provocar el desmontaje o expulsión de medios extraíbles y la actualización de las estructuras de bibliotecas y sistemas de archivos para indicar que el objeto ya no se utiliza. La especificación mínima del cierre hace referencia al objeto. Además, algunos sistemas de archivos proporcionan la especificación de una disposición del objeto que puede indicar que el objeto se debe descartar y ya no será parte del sistema de archivos. De manera similar a la apertura, se debe esperar que algo salga mal.
Las consideraciones para manejar una falla son similares a las de una situación abierta.
La información sobre los datos de un archivo se llama metadatos.
El sistema de archivos conserva algunos de los metadatos, por ejemplo, la fecha de la última modificación (y otras fechas según el sistema de archivos), la ubicación del comienzo del archivo, el tamaño del archivo y si la utilidad de copia de seguridad del sistema de archivos ha guardado la versión actual de los archivos. Estos elementos normalmente no pueden ser modificados por un programa de usuario.
Los metadatos adicionales que admiten algunos sistemas de archivos pueden incluir el propietario del archivo, el grupo al que pertenece el archivo, así como los permisos y/o el control de acceso (es decir, qué acceso y actualizaciones pueden realizar los distintos usuarios o grupos) y si el archivo normalmente está visible cuando se incluye el directorio. Estos elementos suelen ser modificables por las utilidades del sistema de archivos que puede ejecutar el propietario.
Algunas aplicaciones almacenan más metadatos. En el caso de las imágenes, los metadatos pueden incluir el modelo de la cámara y la configuración utilizada para tomar la foto. En el caso de los archivos de audio, los metadatos pueden incluir el álbum, el artista que realizó la grabación y los comentarios sobre la grabación que pueden ser específicos de una copia particular del archivo (es decir, diferentes copias de la misma grabación pueden tener diferentes comentarios, tal como los actualiza el propietario del archivo). Los documentos pueden incluir elementos como revisado por, aprobado por, etc.
Renombrar un archivo, mover un archivo (o un subdirectorio) de un directorio a otro y eliminar un archivo son ejemplos de las operaciones que proporciona el sistema de archivos para la gestión de directorios.
Generalmente se incluyen operaciones de metadatos como permitir o restringir el acceso a un directorio a varios usuarios o grupos de usuarios.
A medida que se utiliza un sistema de archivos, se pueden agregar, eliminar o modificar directorios, archivos y registros. Esto suele provocar ineficiencias en las estructuras de datos subyacentes. Por ejemplo, bloques secuenciales lógicos distribuidos en los medios de una manera que provoca un reposicionamiento excesivo, bloques parcialmente utilizados o incluso vacíos incluidos en estructuras vinculadas. Las estructuras incompletas u otras inconsistencias pueden deberse a errores del dispositivo o del medio, tiempo inadecuado entre la detección de una pérdida inminente de energía y la pérdida de energía real, apagado inadecuado del sistema o eliminación del medio y, en ocasiones muy raras, errores de codificación del sistema de archivos.
Se incluyen rutinas especializadas en el sistema de archivos para optimizar o reparar estas estructuras. Por lo general, no las invoca directamente el usuario, sino que se activan dentro del propio sistema de archivos. Los contadores internos de la cantidad de niveles de estructuras y la cantidad de objetos insertados se pueden comparar con umbrales. Estos pueden hacer que se suspenda el acceso del usuario a una estructura específica (generalmente para disgusto del usuario o usuarios afectados) o pueden iniciarse como tareas asincrónicas de baja prioridad o pueden diferirse hasta un momento de baja actividad del usuario. A veces, estas rutinas son invocadas o programadas por el administrador del sistema o como en el caso de la desfragmentación .
La API es "de nivel kernel" cuando el kernel no sólo proporciona las interfaces para los desarrolladores de sistemas de archivos sino que también es el espacio en el que reside el código del sistema de archivos.
Se diferencia del esquema antiguo en que el propio núcleo utiliza sus propias facilidades para comunicarse con el controlador del sistema de archivos y viceversa, a diferencia de que el núcleo es el que maneja la disposición del sistema de archivos y el sistema de archivos el que accede directamente al hardware.
No es el esquema más limpio pero resuelve las dificultades de reescritura importante que tenía el esquema antiguo.
Con núcleos modulares, se pueden añadir sistemas de archivos como cualquier módulo del núcleo, incluso los de terceros. Sin embargo, con núcleos no modulares, es necesario volver a compilar el núcleo con el nuevo código del sistema de archivos (y en los núcleos de código cerrado, esto hace que los sistemas de archivos de terceros sean imposibles).
Los sistemas Unix y similares, como Linux, han utilizado este esquema modular.
Existe una variación de este esquema que se utiliza en MS-DOS (DOS 4.0 en adelante) y compatibles para soportar sistemas de archivos de red y CD-ROM. En lugar de agregar código al núcleo, como en el esquema anterior, o usar las funciones del núcleo como en el esquema basado en el núcleo, captura todas las llamadas a un archivo e identifica si debe ser redirigido a la función equivalente del núcleo o si debe ser manejado por el controlador del sistema de archivos específico, y el controlador del sistema de archivos accede "directamente" al contenido del disco usando funciones de BIOS de bajo nivel.
La API está "basada en controladores" cuando el núcleo proporciona facilidades pero el código del sistema de archivos reside totalmente externo al núcleo (ni siquiera como un módulo de un núcleo modular).
Es un esquema más limpio ya que el código del sistema de archivos es totalmente independiente, permite crear sistemas de archivos para núcleos de código cerrado y agregar o eliminar sistemas de archivos en línea del sistema.
Ejemplos de este esquema son los IFS de Windows NT y OS/2 respectivamente .
En esta API, todos los sistemas de archivos están en el kernel, como en las API basadas en kernel, pero son atrapados automáticamente por otra API, que está basada en controlador, del sistema operativo.
Este esquema se utilizó en Windows 3.1 para proporcionar un controlador de sistema de archivos FAT en modo protegido de 32 bits [ cita requerida ] y en caché (VFAT) que omitió por completo el controlador FAT de DOS en el núcleo (MSDOS.SYS), y más tarde en la serie Windows 9x ( 95 , 98 y Me ) para VFAT, el controlador de sistema de archivos ISO9660 (junto con Joliet), recursos compartidos de red y controladores de sistema de archivos de terceros, así como para agregar a las API originales de DOS la API LFN (que los controladores IFS no solo pueden interceptar las API de archivos DOS ya existentes, sino también agregar otras nuevas desde dentro del ejecutable de modo protegido de 32 bits).
Sin embargo, esa API no estaba completamente documentada y terceros se encontraron en una situación de "hágalo usted mismo" incluso peor que con las API basadas en kernel.
La API está en el espacio del usuario cuando el sistema de archivos no utiliza directamente las facilidades del kernel sino que accede a los discos utilizando funciones de alto nivel del sistema operativo y proporciona funciones en una biblioteca que una serie de utilidades utilizan para acceder al sistema de archivos.
Esto es útil para manejar imágenes de disco.
La ventaja es que un sistema de archivos puede hacerse portable entre sistemas operativos ya que las funciones de alto nivel del sistema operativo que utiliza pueden ser tan comunes como ANSI C, pero la desventaja es que la API es única para cada aplicación que la implementa.
Ejemplos de este esquema son hfsutils y adflib [ enlace muerto permanente ] .
Como todos los sistemas de archivos (al menos los de disco) necesitan funciones equivalentes proporcionadas por el núcleo, es posible portar fácilmente un código de sistema de archivos de una API a otra, incluso si son de diferentes tipos.
Por ejemplo, el controlador ext2 para OS/2 es simplemente un envoltorio del VFS de Linux al IFS de OS/2 y al kernel basado en ext2 de Linux, y el controlador HFS para OS/2 es un puerto de hfsutils al IFS de OS/2. También existe un proyecto que utiliza un controlador IFS de Windows NT para hacer que NTFS funcione en Linux.