stringtranslate.com

Bloqueo de archivos

El bloqueo de archivos es un mecanismo que restringe el acceso a un archivo de computadora , o a una región de un archivo, permitiendo que solo un usuario o proceso lo modifique o lo elimine en un momento específico y evitando la lectura del archivo mientras se modifica o elimina.

Los sistemas implementan el bloqueo para evitar el clásico escenario de actualización intermedia , que es un ejemplo típico de una condición de carrera , al imponer la serialización de los procesos de actualización a cualquier archivo determinado. El siguiente ejemplo ilustra el problema de actualización intermedia:

  1. El proceso A lee un registro de cliente de un archivo que contiene información de la cuenta, incluido el saldo de la cuenta del cliente y el número de teléfono.
  2. El proceso B ahora lee el mismo registro del mismo archivo, por lo que tiene su propia copia.
  3. El proceso A cambia el saldo de la cuenta en su copia del registro del cliente y vuelve a escribir el registro en el archivo.
  4. El proceso B, que todavía tiene el valor original obsoleto del saldo de la cuenta en su copia del registro del cliente, actualiza el saldo de la cuenta y vuelve a escribir el registro del cliente en el archivo.
  5. El proceso B ahora ha escrito su valor de saldo de cuenta obsoleto en el archivo, lo que provoca que se pierdan los cambios realizados por el proceso A.

La mayoría de los sistemas operativos admiten el concepto de bloqueo de registros , lo que significa que se pueden bloquear registros individuales dentro de un archivo determinado, lo que aumenta la cantidad de procesos de actualización simultáneos . El mantenimiento de bases de datos utiliza el bloqueo de archivos, por lo que puede serializar el acceso a todo el archivo físico subyacente a una base de datos. Aunque esto evita que cualquier otro proceso acceda al archivo, puede ser más eficiente que bloquear individualmente muchas regiones del archivo al eliminar la sobrecarga de adquirir y liberar cada bloqueo.

El uso inadecuado de los bloqueos de archivos, como cualquier bloqueo informático , puede provocar un rendimiento deficiente o bloqueos . El bloqueo de archivos también puede referirse a la seguridad adicional que aplica un usuario informático, ya sea mediante la seguridad de Windows, los permisos NTFS o la instalación de un software de bloqueo de archivos de terceros.

En mainframes

IBM fue pionero en el bloqueo de archivos en 1963 para su uso en computadoras mainframe que utilizaban OS/360 , donde se lo denominó "control exclusivo". [1]

En Microsoft Windows

Microsoft Windows utiliza tres mecanismos distintos para administrar el acceso a los archivos compartidos:

  1. utilizando controles de acceso compartido que permiten a las aplicaciones especificar el acceso compartido a todo el archivo para lectura, escritura o eliminación [2]
  2. Uso de bloqueos de rango de bytes para arbitrar el acceso de lectura y escritura a regiones dentro de un solo archivo [3]
  3. Por los sistemas de archivos de Windows que no permiten que los archivos en ejecución se abran para acceso de escritura o eliminación

Windows hereda la semántica de los controles de acceso a recursos compartidos del sistema MS-DOS , donde el uso compartido se introdujo en MS-DOS 3.3. Por lo tanto, una aplicación debe permitir explícitamente el uso compartido cuando abre un archivo; de lo contrario, tiene acceso exclusivo de lectura, escritura y eliminación del archivo hasta que se cierre (se permiten otros tipos de acceso, como los destinados a recuperar los atributos de un archivo).

En el caso de un archivo abierto con acceso compartido, las aplicaciones pueden utilizar el bloqueo de rango de bytes para controlar el acceso a regiones específicas del archivo. Dichos bloqueos de rango de bytes especifican una región del archivo (desplazamiento y longitud) y el tipo de bloqueo (compartido o exclusivo). Tenga en cuenta que no es necesario que la región del archivo que se está bloqueando contenga datos dentro del archivo, y las aplicaciones a veces aprovechan esta capacidad para implementar su funcionalidad.

En el caso de las aplicaciones que utilizan las API de lectura y escritura de archivos en Windows, los sistemas de archivos que se ejecutan en Windows aplican bloqueos de rango de bytes (también denominados bloqueos obligatorios ). En el caso de las aplicaciones que utilizan las API de asignación de archivos en Windows, no se aplican bloqueos de rango de bytes (también denominados bloqueos de aviso). El bloqueo de rango de bytes también puede tener otros efectos secundarios en el sistema Windows. Por ejemplo, el mecanismo de uso compartido de archivos de Windows normalmente deshabilitará el almacenamiento en caché del lado del cliente de un archivo para todos los clientes cuando cualquier cliente utilice bloqueos de rango de bytes . El cliente observará un acceso más lento porque las operaciones de lectura y escritura deben enviarse al servidor donde está almacenado el archivo.

El manejo inadecuado de errores en un programa de aplicación puede provocar que un archivo quede bloqueado (ya sea mediante acceso "compartido" o con bloqueo de archivos por rango de bytes) y otras aplicaciones no puedan acceder a él. Si es así, el usuario puede restaurar el acceso al archivo cerrando manualmente el programa que funciona mal. Esto se hace normalmente a través de la utilidad Administrador de tareas .

El parámetro de modo de uso compartido (dwShareMode) de la función CreateFile[2] (usada para abrir archivos) determina el uso compartido de archivos. El modo de uso compartido se puede especificar para permitir el uso compartido del archivo para acceso de lectura, escritura o eliminación, o cualquier combinación de estos. Los intentos posteriores de abrir el archivo deben ser compatibles con todos los accesos de uso compartido concedidos previamente al archivo. Cuando se cierra el archivo, las restricciones de acceso de uso compartido se ajustan para eliminar las restricciones impuestas por esa apertura de archivo específica.

El tipo de bloqueo de rango de bytes se determina mediante el dwFlagsparámetro de la función LockFileEx[4] que se utiliza para bloquear una región de un archivo. También se puede utilizar la función [5] de la API de Windows , que adquiere un bloqueo exclusivo en la región del archivo.LockFile

Cualquier archivo que contenga un archivo de programa ejecutable que se esté ejecutando actualmente en el sistema informático como un programa (por ejemplo EXE, un archivo de programa binario COM, DLL, CPLu otro formato de archivo de programa) normalmente está bloqueado por el propio sistema operativo, lo que impide que cualquier aplicación lo modifique o lo elimine. Cualquier intento de hacerlo será denegado con un error de violación de uso compartido, a pesar del hecho de que ninguna aplicación abra el archivo de programa. Sin embargo, aún se permite cierto acceso. Por ejemplo, un archivo de aplicación en ejecución se puede renombrar o copiar (leer) incluso mientras se ejecuta.

Las aplicaciones de Windows acceden a los archivos mediante identificadores de archivo . Estos identificadores de archivo se pueden explorar con la utilidad Process Explorer . Esta utilidad también se puede utilizar para forzar el cierre de identificadores sin necesidad de finalizar la aplicación que los contiene. Esto puede provocar un comportamiento indefinido, ya que el programa recibirá un error inesperado al utilizar el identificador de cierre forzado e incluso puede operar en un archivo inesperado, ya que el número de identificador puede reciclarse. [ cita requerida ]

Las ediciones de Microsoft Windows XP y Server 2003 han introducido la capacidad de instantáneas de volumen ( VSS) en NTFS , lo que permite que el software de copia de seguridad acceda a los archivos abiertos a pesar de los bloqueos exclusivos. Sin embargo, a menos que se reescriba el software para admitir específicamente esta función, la instantánea solo será coherente con los fallos , mientras que las aplicaciones compatibles correctamente pueden ayudar al sistema operativo a crear instantáneas "transaccionalmente coherentes". Otros programas comerciales para acceder a archivos bloqueados en Windows incluyen File Access Manager y Open File Manager. Estos funcionan instalando sus propios controladores para acceder a los archivos en modo kernel .

En sistemas tipo Unix

Los sistemas operativos tipo Unix (incluidos Linux y macOS de Apple ) normalmente no bloquean automáticamente los archivos abiertos. Hay varios tipos de mecanismos de bloqueo de archivos disponibles en diferentes versiones de Unix, y muchos sistemas operativos admiten más de un tipo para compatibilidad. El mecanismo más común es fcntl. Otros dos mecanismos de este tipo son flock(2)y lockf(3), cada uno de los cuales puede implementarse encima fcntlo por separado de fcntl. Aunque algunos tipos de bloqueos se pueden configurar para que sean obligatorios, los bloqueos de archivos en Unix son de forma predeterminada de carácter consultivo . Esto significa que los procesos que cooperan pueden usar bloqueos para coordinar el acceso a un archivo entre ellos, pero los procesos que no cooperan también son libres de ignorar los bloqueos y acceder al archivo de la forma que elijan. En otras palabras, los bloqueos de archivos bloquean solo otros bloqueadores de archivos, no la E/S.

Se ofrecen dos tipos de bloqueos: bloqueos compartidos y bloqueos exclusivos. En el caso de fcntl, se pueden aplicar diferentes tipos de bloqueos a diferentes secciones (rangos de bytes) de un archivo, o bien a todo el archivo. Los bloqueos compartidos pueden ser mantenidos por múltiples procesos al mismo tiempo, pero un bloqueo exclusivo solo puede ser mantenido por un proceso, y no puede coexistir con un bloqueo compartido. Para adquirir un bloqueo compartido, un proceso debe esperar hasta que ningún proceso tenga bloqueos exclusivos. Para adquirir un bloqueo exclusivo, un proceso debe esperar hasta que ningún proceso tenga ninguno de los dos tipos de bloqueo. A diferencia de los bloqueos creados por fcntl, los creados por flockse conservan en forklos s, lo que los hace útiles en servidores de bifurcación. Por lo tanto, es posible que más de un proceso tenga un bloqueo exclusivo en el mismo archivo, siempre que estos procesos compartan una relación filial y el bloqueo exclusivo se haya creado inicialmente en un solo proceso antes de duplicarse en un fork.

Los bloqueos compartidos a veces se denominan "bloqueos de lectura" y los bloqueos exclusivos a veces se denominan "bloqueos de escritura". Sin embargo, debido a que los bloqueos en Unix son consultivos, esto no se aplica. Por lo tanto, es posible que una base de datos tenga un concepto de "escrituras compartidas" frente a "escrituras exclusivas"; por ejemplo, cambiar un campo en su lugar puede estar permitido bajo acceso compartido, mientras que la recolección de basura y la reescritura de la base de datos pueden requerir acceso exclusivo.

Los bloqueos de archivos se aplican al archivo en sí, no al nombre del archivo. Esto es importante porque Unix permite que varios nombres hagan referencia al mismo archivo. Junto con el bloqueo no obligatorio, esto genera una gran flexibilidad para acceder a los archivos desde varios procesos. Por otro lado, el enfoque de bloqueo cooperativo puede generar problemas cuando un proceso escribe en un archivo sin obedecer los bloqueos de archivo establecidos por otros procesos.

Por esta razón, algunos sistemas operativos tipo Unix también ofrecen soporte limitado para el bloqueo obligatorio . [6] En tales sistemas, un archivo cuyo setgidbit está activado pero cuyo bit de ejecución de grupo está desactivado cuando se abre ese archivo estará sujeto a un bloqueo obligatorio automático si el sistema de archivos subyacente lo admite. Sin embargo, las particiones NFS no locales tienden a ignorar este bit. [7] Si un archivo está sujeto a bloqueo obligatorio, los intentos de leer desde una región bloqueada con un bloqueo exclusivo, o escribir en una región bloqueada con un bloqueo compartido o exclusivo, se bloquearán hasta que se libere el bloqueo. Esta estrategia se originó por primera vez en System V y se puede ver hoy en los sistemas operativos Solaris , HP-UX y Linux. Sin embargo, no es parte de POSIX, y los sistemas operativos derivados de BSD como FreeBSD , OpenBSD , NetBSD y macOS de Apple no lo admiten. [8] Linux también admite el bloqueo obligatorio a través del parámetro especial -o mandpara el montaje del sistema de archivos ( mount(8)), pero esto rara vez se usa.

Algunos sistemas operativos tipo Unix impiden los intentos de abrir el archivo ejecutable de un programa en ejecución para escribir; esta es una tercera forma de bloqueo, separada de las proporcionadas por fcntly flock.

Problemas

Más de un proceso puede mantener un bloqueo exclusivo flocken un archivo determinado si el bloqueo exclusivo se duplicó en un archivo posterior fork. Esto simplifica la codificación para servidores de red y ayuda a prevenir condiciones de carrera, pero puede resultar confuso para quienes no lo saben.

Los bloqueos obligatorios no tienen efecto sobre la unlinkllamada al sistema. En consecuencia, ciertos programas pueden, efectivamente, eludir el bloqueo obligatorio. Stevens y Rago (2005) observaron que el ededitor efectivamente lo hizo. [9]

El flockfuncionamiento de los bloqueos en sistemas de archivos de red, como NFS , depende de la implementación. En sistemas BSD , flocklas llamadas a un descriptor de archivo abierto a un archivo en una partición montada en NFS son operaciones sin éxito . En Linux anterior a la versión 2.6.12, flocklas llamadas a archivos NFS actuarían solo localmente. El kernel 2.6.12 y posteriores implementan flockllamadas a archivos NFS utilizando bloqueos de rango de bytes POSIX. Estos bloqueos serán visibles para otros clientes NFS que implementen bloqueos POSIXfcntl de estilo , pero invisibles para aquellos que no lo hagan. [10]

Las actualizaciones y degradaciones de bloqueo liberan el bloqueo anterior antes de aplicar el nuevo. Si una aplicación degrada un bloqueo exclusivo a un bloqueo compartido mientras otra aplicación está bloqueada esperando un bloqueo exclusivo, la última aplicación puede obtener el bloqueo exclusivo y bloquear la primera aplicación. Esto significa que las degradaciones de bloqueo pueden generar bloqueos, lo que puede resultar contraintuitivo.

Todos fcntl los bloqueos asociados con un archivo para un proceso determinado se eliminan cuando el proceso cierra cualquierfcntl descriptor de archivo para ese archivo, incluso si nunca se solicitó un bloqueo para ese descriptor de archivo. Además, los bloqueos no son heredados por un proceso secundario. La fcntlsemántica de cierre es particularmente problemática para las aplicaciones que llaman a bibliotecas de subrutinas que pueden acceder a archivos. Ninguno de estos "errores" ocurre al usar flockbloqueos de estilo real.

La preservación del estado de bloqueo en los descriptores de archivos abiertos pasados ​​a otro proceso mediante un socket de dominio Unix depende de la implementación.

Problemas de E/S almacenados en búfer

Una fuente de falla de bloqueo ocurre cuando la E/S con búfer tiene búferes asignados en el espacio de trabajo local del usuario, en lugar de en un grupo de búferes del sistema operativo. fready fwritese usan comúnmente para hacer E/S con búfer, y una vez que se lee una sección de un archivo, otro intento de leer esa misma sección, muy probablemente, obtendrá los datos del búfer local. El problema es que otro usuario adjunto al mismo archivo tiene sus propios búferes locales, y lo mismo les está sucediendo. Un fwritede los datos obtenidos del búfer por nofread obtendrá los datos del archivo en sí, y algún otro usuario podría haberlo cambiado. Ambos podrían usar para asegurar el acceso exclusivo, lo que evita escrituras simultáneas, pero dado que las lecturas se leen desde el búfer y no desde el archivo en sí, cualquier dato cambiado por el usuario n.º 1 puede ser perdido por el usuario n.º 2 (sobrescrito). La mejor solución a este problema es usar E/S sin búfer ( y ) con , lo que también significa usar en lugar de y . Por supuesto, tendrá que hacer ajustes para los parámetros de la función y los resultados devueltos. En términos generales, la E/S almacenada en búfer no es segura cuando se utiliza con archivos compartidos.flockreadwriteflocklseekfseekftell

En AmigaOS

En AmigaOS , se puede adquirir un bloqueo sobre un archivo (o directorio) utilizando la Lockfunción (en el dos.library). Un bloqueo puede ser compartido (otros procesos pueden leer el archivo/directorio, pero no pueden modificarlo ni eliminarlo) o exclusivo, de modo que solo el proceso que adquiere exitosamente el bloqueo puede acceder o modificar el objeto. El bloqueo está sobre el objeto completo y no sobre una parte de él. El bloqueo debe liberarse con la UnLockfunción: a diferencia de Unix, el sistema operativo no desbloquea implícitamente el objeto cuando el proceso termina.

Bloquear archivos

Los scripts de shell y otros programas suelen utilizar una estrategia similar al uso del bloqueo de archivos: la creación de archivos de bloqueo , que son archivos cuyo contenido es irrelevante (aunque a menudo se encontrará el identificador de proceso del titular del bloqueo en el archivo) y cuyo único propósito es señalar con su presencia que algún recurso está bloqueado. Un archivo de bloqueo suele ser el mejor enfoque si el recurso que se va a controlar no es un archivo normal en absoluto, por lo que el uso de métodos para bloquear archivos no se aplica. Por ejemplo, un archivo de bloqueo puede gobernar el acceso a un conjunto de recursos relacionados, como varios archivos diferentes, directorios, un grupo de particiones de disco o acceso seleccionado a protocolos de nivel superior como servidores o conexiones de bases de datos.

Al utilizar archivos de bloqueo, se debe tener cuidado de garantizar que las operaciones sean atómicas . Para obtener un bloqueo, el proceso debe verificar que el archivo de bloqueo no exista y luego crearlo, mientras evita que otro proceso lo cree mientras tanto. Entre los métodos para hacerlo se incluyen los siguientes:

Los archivos bloqueados suelen nombrarse con una tilde ( ~) antes del nombre del archivo que están bloqueando, o con un duplicado del nombre completo del archivo con el sufijo .LCK . Si están bloqueando un recurso que no sea un archivo, pueden tener un nombre más arbitrario.

Software de desbloqueo

Un desbloqueador es una utilidad que se utiliza para determinar qué proceso está bloqueando un archivo y muestra una lista de procesos, así como opciones sobre qué hacer con el proceso (eliminar tarea, desbloquear, etc.) junto con una lista de opciones de archivo, como eliminar o cambiar el nombre. Su propósito es eliminar bloqueos de archivos incorrectos o obsoletos, que a menudo surgen de situaciones anómalas, como procesos bloqueados o colgados, que conducen a bloqueos de archivos que persisten a pesar de que el proceso propietario ya haya muerto. En algunos sistemas tipo Unix, se pueden utilizar utilidades como fstaty lockfpara inspeccionar el estado de los bloqueos de archivos por proceso, por nombre de archivo o ambos. [ cita requerida ]

En los sistemas Windows, si un archivo está bloqueado, es posible programar su traslado o eliminación para que se realice en el próximo reinicio. Este enfoque lo suelen utilizar los instaladores para reemplazar archivos de sistema bloqueados.

Sistemas de control de versiones

En los sistemas de control de versiones, el bloqueo de archivos se utiliza para evitar que dos usuarios cambien la misma versión de archivo en paralelo y, luego, al guardar, el segundo usuario sobrescriba lo que cambió el primer usuario. Esto se implementa marcando los archivos bloqueados como de solo lectura en el sistema de archivos. Un usuario que desee cambiar el archivo realiza una operación de desbloqueo (también llamada extracción) y, hasta que se realice una operación de registro (almacenamiento) o se revierta el bloqueo, nadie más puede desbloquear el archivo.

Véase también

Referencias

  1. ^ Sistema operativo IBM System/360: Referencia del lenguaje de control de trabajos (PDF) . IBM . Junio ​​de 1971. págs. 162–164. GC28-6704-1.
  2. ^ ab "Función CreateFileW". Kit de herramientas de desarrollo de software de Windows. Microsoft Docs . windows-sdk-content. Microsoft Corporation . Consultado el 7 de noviembre de 2018 .
  3. ^ "Función LockFileEx". Kit de herramientas de desarrollo de software de Windows. Microsoft Docs . windows-sdk-content. Microsoft Corporation . Consultado el 7 de noviembre de 2018 .
  4. ^ "Función LockFileEx". Kit de herramientas de desarrollo de software de Windows. Microsoft Docs . windows-sdk-content. Microsoft Corporation . Consultado el 5 de julio de 2020 .
  5. ^ "Función LockFile". Kit de herramientas de desarrollo de software de Windows. Microsoft Docs . windows-sdk-content. Microsoft Corporation . Consultado el 5 de julio de 2020 .
  6. ^ "Bloqueo obligatorio de archivos para el sistema operativo Linux". kernel.org . Documentación / Sistemas de archivos . Consultado el 8 de octubre de 2011 .
  7. ^ "Utilice Setuid, Setgid y Sticky Bits con Server for NFS". cc731734(WS.10) . Consultado el 8 de octubre de 2011 .
  8. ^ Viega, John; Messier, Matt (2003). "2.8 Bloqueo de archivos". Libro de recetas de programación segura para C y C++ (1.ª ed.). Sabastopol, CA: O'Reilly Media. pág. 792. ISBN 978-0-596-00394-4La compatibilidad con bloqueos obligatorios varía mucho de una variante de Unix a otra. Tanto Linux como Solaris admiten bloqueos obligatorios, pero Darwin , FreeBSD , NetBSD y OpenBSD no, a pesar de que exportan la interfaz utilizada por Linux y Solaris para admitirlos. En dichos sistemas, esta interfaz crea bloqueos de aviso. La compatibilidad con bloqueos obligatorios no se extiende a NFS.
  9. ^ Stevens, W. Richard; Rago, Stephen A. (27 de junio de 2005). Programación avanzada en el entorno UNIX (segunda edición). Addison-Wesley Professional. pág. 456. ISBN 978-0201433074.
  10. ^ "Mensajes de error que ocurren con frecuencia". nfs.sourceforge.net . Preguntas frecuentes sobre NFS para Linux: D. Source Forge.
  11. ^ "Bloquea tu script (para evitar su ejecución en paralelo)". Archivado desde el original el 1 de agosto de 2010.{{cite web}}: CS1 maint: unfit URL (link)

Enlaces externos