Una API de sistema de archivos es una interfaz de programación de aplicaciones a través de 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 del sistema de archivos también pueden incluir interfaces para operaciones de mantenimiento, como crear o inicializar un sistema de archivos, verificar la integridad del sistema de archivos y desfragmentar .
Cada sistema operativo incluye las API necesarias para los sistemas de archivos que admite. Microsoft Windows tiene API de sistema 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.
Historia
Algunos de los primeros sistemas operativos eran capaces de manejar solo sistemas de archivos de cinta y disco . Estos proporcionaron las interfaces más básicas con:
- Escribir, leer y posicionar
Una mayor coordinación, como la asignación y desasignación de dispositivos, requirió la adición de:
- Abrir y cerrar
A medida que los sistemas de archivos proporcionaron 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 adicionales, la estructura jerárquica y los medios admitidos, las características adicionales necesitaban algunas funciones especializadas:
- Gestión de directorios
- Gestión de la estructura de datos
- Gestión de registros
- Operaciones sin datos
Los sistemas multiusuario requerían API para:
- Intercambio
- Restringir el acceso
- Cifrado
Descripción general de la API
Escribir, leer y posicionar
La escritura de datos de usuario en un sistema de archivos se proporciona para que la utilice directamente el programa de usuario o la biblioteca de tiempo de ejecución. La biblioteca en tiempo de ejecución para algunos lenguajes de programación puede proporcionar conversión, formato y bloqueo de tipos. 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 llama PUT
o PUTX
(si el registro existe)
La lectura de los datos del 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 con la escritura, las bibliotecas en tiempo de ejecución pueden interceder por el programa de usuario.
El posicionamiento incluye ajustar la ubicación del siguiente registro. Esto puede incluir saltar hacia adelante o hacia atrás, así como posicionarse al principio o al final del archivo.
Abrir y cerrar
La API abierta puede solicitarse explícitamente o invocarse implícitamente tras la emisión de la primera operación por un proceso en un objeto. Puede provocar el montaje de medios extraíbles, establecer una conexión con otro host y validar la ubicación y 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:
- El objeto al que se va a acceder (archivo, directorio, medio y ubicación)
- El tipo previsto de operaciones que se realizarán después de la apertura (lecturas, actualizaciones, eliminaciones)
Puede ser necesaria información adicional, por ejemplo
- una contraseña
- una declaración de que otros procesos pueden acceder al mismo objeto mientras el proceso de apertura está usando el objeto (compartir). Esto puede depender de la intención del otro proceso. Por el contrario, una declaración de que ningún otro proceso puede acceder al objeto independientemente de la intención del otro proceso (uso exclusivo).
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 enviar la solicitud al sistema de archivos.
Es de esperar que algo salga mal durante el procesamiento de la apertura.
- El objeto o la intención pueden estar incorrectamente especificados (el nombre puede incluir un carácter inaceptable o la intención no se reconoce).
- Es posible que el proceso tenga prohibido acceder al objeto (es posible que solo un grupo o un usuario específico pueda acceder a él).
- 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 soporte.
Dependiendo del lenguaje de programación, especificaciones adicionales al aire libre 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 de apertura no pueda realizar ninguna acción significativa como resultado de una falla. Por ejemplo, si la falla está en el intento de abrir el archivo de entrada necesario, la única acción puede ser informar la falla y abortar el programa. Algunos lenguajes simplemente devuelven un código que indica el tipo de falla que siempre debe ser verificado por el programa, que decide qué reportar y si puede continuar.
El cierre puede provocar el desmontaje o la expulsión de los medios extraíbles y la actualización de las estructuras de la biblioteca y el sistema de archivos para indicar que el objeto ya no está en uso. La especificación mínima al 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 descartará y ya no será parte del sistema de archivos. Al igual que con el abierto, se debe esperar que algo salga mal.
- La especificación del objeto puede ser incorrecta.
- Es posible que no haya suficiente capacidad en los medios para guardar los datos que se están almacenando en el búfer o para generar una estructura que indique que el objeto se actualizó correctamente.
- Puede ocurrir un error de dispositivo en los medios donde se almacena el objeto mientras se escriben los datos almacenados en el búfer, la estructura de finalización o se actualizan los metadatos relacionados con el objeto (por ejemplo, la hora del último acceso).
- Una especificación para liberar el objeto puede ser inconsistente con otros procesos que aún usan el objeto.
Las consideraciones para manejar una falla son similares a las del abierto.
Gestión de metadatos
La información sobre los datos de un archivo se denomina metadatos.
Algunos de los metadatos son mantenidos por el sistema de archivos, por ejemplo, la fecha de la última modificación (y varias otras fechas dependiendo del 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 tiene guardó la versión actual de los archivos. Por lo general, un programa de usuario no puede modificar estos elementos.
Los metadatos adicionales admitidos por 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 varios usuarios o grupos) y si el archivo normalmente es visible cuando el directorio está listado. Estos elementos suelen ser modificables por las utilidades del sistema de archivos que puede ejecutar el propietario.
Algunas aplicaciones almacenan más metadatos. Para las imágenes, los metadatos pueden incluir el modelo de cámara y la configuración utilizada para tomar la foto. Para los archivos de audio, los metadatos pueden incluir el álbum, el artista que grabó la grabación y 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 comentarios diferentes según la actualización del propietario del archivo). Los documentos pueden incluir elementos como comprobado, aprobado por, 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 proporciona el sistema de archivos para la gestión de directorios.
Normalmente se incluyen operaciones de metadatos como permitir o restringir el acceso a un directorio por parte de varios usuarios o grupos de usuarios.
Mantenimiento del sistema de archivos
A medida que se utiliza un sistema de archivos, los directorios, archivos y registros pueden agregarse, eliminarse o modificarse. Esto suele causar ineficiencias en las estructuras de datos subyacentes. Cosas como bloques lógicamente secuenciales distribuidos a través de los medios de una manera que causa un reposicionamiento excesivo, incluso bloques vacíos usados parcialmente incluidos en estructuras vinculadas. Las estructuras incompletas u otras inconsistencias pueden ser causadas por errores del dispositivo o de los medios, tiempo inadecuado entre la detección de la pérdida inminente de energía y la pérdida de energía real, apagado incorrecto del sistema o eliminación de medios y, en muy raras ocasiones, 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, el usuario no los invoca directamente, sino que los activa dentro del propio sistema de archivos. Los contadores internos del número de niveles de estructuras, el número de objetos insertados se pueden comparar con los umbrales. Estos pueden hacer que el acceso del usuario se suspenda a una estructura específica (generalmente para disgusto del usuario o de los usuarios afectados) o pueden iniciarse como tareas asíncronas de baja prioridad o pueden diferirse a 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 .
API de nivel de kernel
La API es "a nivel de kernel" cuando el kernel no solo 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 anterior en que el propio kernel utiliza sus propias instalaciones para hablar con el controlador del sistema de archivos y viceversa, ya que, al contrario, el kernel es el que maneja el diseño del sistema de archivos y el sistema de archivos es el que accede directamente al hardware.
No es el esquema más limpio pero resuelve las dificultades de reescritura mayor que tiene el esquema anterior.
Con kernels modulares permite agregar sistemas de archivos como cualquier módulo de kernel, incluso de terceros. Sin embargo, con kernels no modulares requiere que el kernel sea recompilado con el nuevo código del sistema de archivos (y en kernels de código cerrado, esto hace que el sistema de archivos de terceros sea imposible).
Unix y Unix-como sistemas 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 admitir CD-ROM y sistemas de archivos de red. En lugar de agregar código al kernel, como en el esquema anterior, o usar las facilidades del kernel como en el esquema basado en el kernel, captura todas las llamadas a un archivo e identifica si debe ser redirigido a la función equivalente del kernel o si tiene que hacerlo. 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 .
API basada en controladores
La API está "basada en controladores" cuando el kernel proporciona instalaciones pero el código del sistema de archivos reside totalmente fuera del kernel (ni siquiera como un módulo de un kernel 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 adiciones o eliminaciones de sistemas de archivos en línea del sistema.
Ejemplos de este esquema son los IFS respectivos de Windows NT y OS / 2 .
API mixta basada en controlador de kernel
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 controladores, por el sistema operativo.
Este esquema se utilizó en Windows 3.1 para proporcionar un controlador de sistema de archivos FAT en modo protegido [ cita requerida ] de 32 bits y en caché, (VFAT) que omitió el controlador FAT de DOS en el kernel (MSDOS.SYS) por completo, y más tarde en el Windows 9x series ( 95 , 98 y Me ) para VFAT, el controlador del sistema de archivos ISO9660 (junto con Joliet), recursos compartidos de red y controladores del sistema de archivos de terceros, además de agregar a las API de DOS originales la API de LFN (que los controladores IFS no pueden solo interceptar las API de archivos DOS ya existentes, pero también agregar nuevas desde el ejecutable en modo protegido de 32 bits).
Sin embargo, esa API no estaba completamente documentada, y los terceros se encontraron en un escenario de "hágalo usted mismo" incluso peor que con las API basadas en kernel.
API de espacio de usuario
La API está en el espacio del usuario cuando el sistema de archivos no usa directamente las instalaciones del kernel, pero accede a los discos usando funciones de alto nivel del sistema operativo y proporciona funciones en una biblioteca que una serie de utilidades usan para acceder al sistema de archivos.
Esto es útil para manejar imágenes de disco.
La ventaja es que un sistema de archivos se puede convertir en portátil entre sistemas operativos, ya que las funciones del sistema operativo de alto nivel que utiliza pueden ser tan comunes como ANSI C, pero la desventaja es que la API es única para cada aplicación que implementa una.
Ejemplos de este esquema son hfsutils y adflib [ enlace muerto permanente ] .
Interoperatibilidad entre las API del sistema de archivos
Como todos los sistemas de archivos (al menos los de disco) necesitan funciones equivalentes proporcionadas por el kernel, es posible transferir 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 una envoltura del VFS de Linux al IFS de OS / 2 y el controlador ext2 de Linux basado en el kernel, y el controlador HFS para OS / 2 es un puerto de hfsutils al OS / 2 de IFS. También existe un proyecto que utiliza un controlador IFS de Windows NT para que NTFS funcione en Linux.
Ver también
Referencias
Fuentes
- O'Reilly - Elementos internos del sistema de archivos de Windows NT, una guía para desarrolladores - Por Rajeev Nagar - ISBN 1-56592-249-2
- Microsoft Press - Dentro del sistema de archivos de Windows NT - Por Helen Custer - ISBN 1-55615-660-X
- Wiley - Sistemas de archivos UNIX: evolución, diseño e implementación - Por Steve D. Pate - ISBN 0-471-16483-6
- Microsoft Press - Dentro de Windows NT - Por Helen Custer - ISBN 1-55615-481-X
enlaces externos
- Especificaciones del sistema de archivos y documentos técnicos
- Un recorrido por el VFS de Linux
- IFSKit de Microsoft
- hfsutils
- adflib [ enlace muerto permanente ]
- Un sistema de abstracción del sistema de archivos para Go