Una API de sistema de archivos es una interfaz de programación de aplicaciones mediante la cual una utilidad o 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 cuenta con API para los sistemas de archivos NTFS y varios sistemas FAT . Los sistemas Linux pueden incluir API para ext2 , ext3 , ReiserFS y Btrfs , entre otros.
Historia
Algunos de los primeros sistemas operativos solo eran capaces de manejar sistemas de archivos en cinta y disco. Estos proporcionaban las interfaces más básicas con:
- Escribir, leer y posicionarse
Se requirió una mayor coordinación, como la asignación y desasignación de dispositivos, para la incorporación de:
- Abrir y cerrar
A medida que los sistemas de archivos proporcionaban más servicios, se definieron más interfaces:
- Gestión de metadatos
- Mantenimiento del sistema de archivos
A medida que aumentaban los tipos de sistemas de archivos, la estructura jerárquica y los medios compatibles, las funciones adicionales requerían algunas funciones especializadas:
- Gestión de directorios
- Gestión de la estructura de datos
- Gestión de registros
- Operaciones que no se basan en datos
Los sistemas multiusuario requerían API para:
- Intercambio
- Restringir el acceso
- Cifrado
Resumen de la API
Escribir, leer y posicionarse
La escritura de datos de usuario en un sistema de archivos está disponible para su uso directo por el programa de usuario o la biblioteca de tiempo de ejecución. La biblioteca de tiempo de ejecución para algunos lenguajes de programación puede proporcionar conversión de tipos, formato y bloqueo. Algunos sistemas de archivos permiten la identificación de registros mediante claves y pueden incluir la reescritura de un registro existente. Esta operación a veces se denomina PUTo PUTX(si el registro existe).
La lectura de datos de usuario, a veces denominada 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 al escribir, las bibliotecas de tiempo de ejecución pueden intervenir para el programa de usuario.
El posicionamiento incluye ajustar la ubicación del siguiente registro. Esto puede incluir avanzar o retroceder, así como posicionarse al principio o al final del archivo.
Abrir y cerrar
La API abierta puede solicitarse explícitamente o invocarse implícitamente al realizar 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. Además, 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:
- El objeto al que se va a acceder (archivo, directorio, medio y ubicación)
- El tipo de operaciones que se pretenden realizar después de la apertura (lecturas, actualizaciones, eliminaciones)
Puede que sea necesaria información adicional, por ejemplo:
- una contraseña
- Una declaración que permite que otros procesos accedan al mismo objeto mientras el proceso que lo abre lo está utilizando (compartición). Esto puede depender de la intención del otro proceso. Por el contrario, una declaración que impide que cualquier otro proceso acceda al objeto, independientemente de su intención (uso exclusivo). Estas declaraciones se solicitan mediante una biblioteca de lenguaje de programación que puede coordinar los módulos del proceso, además de reenviar la solicitud al sistema de archivos.
Cabe esperar que algo pueda salir mal durante el procesamiento de la apertura:
- Es posible que el objeto o la intención no estén especificados correctamente (el nombre puede incluir un carácter inaceptable o la intención no se reconoce).
- Es posible que el proceso tenga prohibido el acceso al objeto (puede que solo sea accesible para un grupo o un usuario específico).
- Es posible que el sistema de archivos no pueda crear o actualizar las estructuras necesarias para coordinar las actividades entre los usuarios.
- En el caso de un objeto nuevo (o de reemplazo), es posible que no haya suficiente capacidad en el medio de almacenamiento.
Dependiendo del lenguaje de programación, las especificaciones adicionales en el código 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 abre el archivo no pueda realizar ninguna acción útil debido a un fallo.
El cierre puede provocar el desmontaje o la expulsión de medios extraíbles y la actualización de las estructuras de la biblioteca y del sistema de archivos para indicar que el objeto ya no está en uso. La especificación mínima para el cierre hace referencia al objeto. Además, algunos sistemas de archivos permiten especificar una disposición del objeto que puede indicar que este debe descartarse y dejar de formar parte del sistema de archivos.
Al igual que en la apertura, cabe esperar que algo pueda salir mal:
- La especificación del objeto puede ser incorrecta.
- Es posible que el medio de almacenamiento no tenga capacidad suficiente para guardar los datos que se están almacenando en búfer o para generar una estructura que indique que el objeto se actualizó correctamente.
- Puede producirse un error en el dispositivo de almacenamiento donde se guarda el objeto al escribir datos en búfer, al modificar la estructura de finalización o al actualizar los metadatos relacionados con el objeto (por ejemplo, la hora del último acceso).
- Una especificación para liberar el objeto puede ser incompatible con otros procesos que aún lo estén utilizando.
Las consideraciones para gestionar un fallo son similares a las de un caso abierto.
Gestión de metadatos
La información sobre los datos que contiene un archivo se denomina metadatos.
Algunos metadatos son gestionados por el sistema de archivos, como la fecha de última modificación (y otras fechas que varían según el sistema), la ubicación del inicio del archivo, su tamaño y si la utilidad de copia de seguridad del sistema de archivos ha guardado la versión actual. Estos elementos generalmente no pueden ser modificados por un programa de usuario.
Algunos sistemas de archivos admiten metadatos adicionales, como el propietario del archivo, el grupo al que pertenece, los permisos y el control de acceso (es decir, qué accesos y actualizaciones pueden realizar los distintos usuarios o grupos), y si el archivo es visible normalmente al listar el directorio. Estos elementos suelen ser modificables mediante 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 grabó la grabación y comentarios sobre la misma, que pueden ser específicos de una copia particular del archivo (es decir, diferentes copias de la misma grabación pueden tener comentarios distintos, ya que el propietario del archivo los actualiza). Los documentos pueden incluir información como quién los revisó, quién los aprobó, etc.
Gestión de directorios
Cambiar el nombre de un archivo, mover un archivo (o un subdirectorio) de un directorio a otro y eliminar un archivo son ejemplos de las operaciones que ofrece el sistema de archivos para la gestión de directorios.
Por lo general, se incluyen operaciones de metadatos, como permitir o restringir el acceso a un directorio por parte de distintos usuarios o grupos de usuarios.
Mantenimiento del sistema de archivos
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 lógicamente secuenciales distribuidos en el medio de almacenamiento de forma que se produzca 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 de almacenamiento, un tiempo insuficiente entre la detección de una pérdida de energía inminente y la pérdida de energía real, un apagado incorrecto del sistema o la extracción del medio de almacenamiento y, en muy raras ocasiones, errores de codificación del sistema de archivos.
El sistema de archivos incluye rutinas especializadas para optimizar o reparar estas estructuras. Generalmente, el usuario no las invoca directamente, sino que se activan dentro del propio sistema de archivos. Se pueden comparar contadores internos del número de niveles de estructuras y del número de objetos insertados con umbrales. Esto puede provocar la suspensión del acceso del usuario a una estructura específica (lo que suele generar descontento entre el usuario o los usuarios afectados), iniciarlas como tareas asíncronas de baja prioridad o posponerlas a un momento de baja actividad del usuario. En ocasiones, estas rutinas son invocadas o programadas por el administrador del sistema, como en el caso de la desfragmentación.
API a nivel de kernel
La API es de nivel de kernel cuando el kernel no solo proporciona las interfaces para los desarrolladores del sistema de archivos, sino que también es el espacio en el que reside el código del sistema de archivos.
Se diferencia del esquema anterior en que el propio núcleo utiliza sus propias herramientas para comunicarse con el controlador del sistema de archivos y viceversa, a diferencia de la situación anterior, en la que el núcleo se encargaba de la estructura del sistema de archivos y el sistema de archivos era el que accedía directamente al hardware.
It is not the cleanest scheme but resolves the difficulties of major rewrite that has the old scheme.
With modular kernels it allows adding file systems as any kernel module, even third party ones. With non-modular kernels however it requires the kernel to be recompiled with the new file-system code (and in closed-source kernels, this makes third-party file systems impossible).
Unixes and Unix-like systems such as Linux have used this modular scheme.
There is a variation of this scheme used in MS-DOS (DOS 4.0 onward) and compatibles to support CD-ROM and network file systems. Instead of adding code to the kernel, as in the old scheme, or using kernel facilities as in the kernel-based scheme, it traps all calls to a file and identifies if it should be redirected to the kernel's equivalent function or if it has to be handled by the specific file-system driver, and the file-system driver directly accesses the disk contents using low-level BIOS functions.
Driver-based API
The API is driver-based when the kernel provides facilities but the file system code resides totally external to the kernel (not even as a module of a modular kernel).
It is a cleaner scheme as the file-system code is totally independent, it allows file systems to be created for closed-source kernels and online file system additions or removals from the system.
Examples of this scheme are the Windows NT and OS/2 respective Installable File Systems (IFSs).
Mixed kernel-driver-based API
In this API, all file systems are in the kernel, like in kernel-based APIs, but they are automatically trapped by another API, that is driver-based, by the OS.
User space API
The API is in the user space when the file system does not directly use kernel facilities but accesses disks using high-level operating system functions and provides functions in a library that a series of utilities use to access the file system.
This is useful for handling disk images.
The advantage is that a file system can be made portable between operating systems as the high-level operating system functions it uses can be as common as ANSI C, but the disadvantage is that the API is unique to each application that implements one.
Examples of this scheme are the hfsutils and the adflib.
Interoperatibility between file system APIs
As all disk file systems need equivalent functions provided by the kernel, it is possible to easily port file-system code from one API to another, even if they are of different types.
See also
References
Sources
- Custer, Helen (1993). Inside Windows NT . Microsoft Press . ISBN 1-55615-481-X.
- Custer, Helen (1994). Inside Windows NT File System . Microsoft Press. ISBN 1-55615-660-X.
- Nagar, Rajeev (1997). Windows NT File System Internals, A Developer's Guide . O'Reilly Media . ISBN 1-56592-249-2.
- Pate, Steve D. (2003). Sistemas de archivos UNIX: Evolución, diseño e implementación . Wiley . ISBN 0-471-16483-6.
Enlaces externos
- Un recorrido por el VFS de Linux
- IFSKit de Microsoft
- Interfaces de programación de aplicaciones
- Sistemas de archivos informáticos