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, al permitir que solo un usuario o proceso lo modifique o elimine en un momento específico y evita 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 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 el registro de un cliente de un archivo que contiene información de la cuenta, incluido el saldo de la cuenta y el número de teléfono del cliente.
  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 escribe el registro del cliente nuevamente 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 los registros individuales dentro de un archivo determinado pueden bloquearse, aumentando así el número de procesos de actualización simultáneos . El mantenimiento de la base de datos utiliza el bloqueo de archivos, mediante el cual 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 mal uso de los bloqueos de archivos, como cualquier bloqueo de computadora , puede resultar en un rendimiento deficiente o en puntos muertos . El bloqueo de archivos también puede referirse a la seguridad adicional aplicada por un usuario de computadora, ya sea mediante la seguridad de Windows, permisos NTFS o instalando 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 centrales que usaban OS/360 , donde se lo denominó "control exclusivo". [1]

En Microsoft Windows

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

  1. uso de controles de acceso compartido que permiten a las aplicaciones especificar el acceso compartido a archivos completos para lectura, escritura o eliminación [2]
  2. usar 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 compartido del sistema MS-DOS , donde se introdujo el uso compartido en MS-DOS 3.3. Por lo tanto, una aplicación debe permitir explícitamente compartir 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 aquellos para recuperar los atributos de un archivo).

Para un archivo abierto con acceso compartido, las aplicaciones pueden usar el bloqueo de rango de bytes para controlar el acceso a regiones específicas del archivo. Estos 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 bloquea tenga datos dentro del archivo y, en ocasiones, las aplicaciones aprovechan esta capacidad para implementar su funcionalidad.

Para las aplicaciones que utilizan las API de lectura/escritura de archivos en Windows, los sistemas de archivos que se ejecutan dentro de Windows aplican bloqueos de rango de bytes (también conocidos como bloqueos obligatorios ). Para las aplicaciones que utilizan las API de asignación de archivos en Windows, los bloqueos de rango de bytes no se aplican (también conocidos como 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 intercambio de archivos de Windows normalmente deshabilitará el almacenamiento en caché del lado del cliente de un archivo para todos los clientes cuando cualquier cliente utiliza 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 llevar a un escenario en el que un archivo esté bloqueado (ya sea mediante acceso "compartido" o con bloqueo de archivo de rango de bytes) y otras aplicaciones no puedan acceder a él. Si es así, es posible que el usuario pueda restaurar el acceso a los archivos finalizando manualmente el programa que no funciona correctamente. Normalmente, esto se hace a través de la utilidad Administrador de tareas .

El parámetro del modo de compartir (dwShareMode) de la función CreateFile[2] (utilizado para abrir archivos) determina el uso compartido de archivos. El modo de compartir se puede especificar para permitir compartir el 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 compartidos previamente otorgados al archivo. Cuando se cierra el archivo, las restricciones de acceso compartido se ajustan para eliminar las restricciones impuestas por la apertura de ese archivo específico.

El tipo de bloqueo de rango de bytes está determinado por el dwFlagsparámetro en la función LockFileEx[4] utilizada para bloquear una región de un archivo. La función API de Windows LockFile[5] también se puede utilizar y adquiere un bloqueo exclusivo en la región del archivo.

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 formato de archivo de programa binario COM, DLLu CPLotro formato de programa binario) normalmente está bloqueado por el propio sistema operativo, impidiendo que cualquier aplicación lo modifique o lo elimine. Cualquier intento de hacerlo será rechazado con un error de infracción de uso compartido, a pesar de que ninguna aplicación abre el archivo del programa. Sin embargo, todavía se permite cierto acceso. Por ejemplo, un archivo de aplicación en ejecución se puede cambiar de nombre o copiar (leer) incluso durante la ejecución.

Las aplicaciones de Windows acceden a los archivos mediante identificadores de archivos . Estos identificadores de archivos 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 causar un comportamiento indefinido, ya que el programa recibirá un error inesperado al usar el identificador de cierre forzado e incluso puede operar en un archivo inesperado ya que el número del identificador puede reciclarse. [ cita necesaria ]

Las ediciones 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 el software se reescriba para admitir específicamente esta característica, la instantánea solo será consistente con fallas , mientras que las aplicaciones con soporte adecuado pueden ayudar al sistema operativo a crear instantáneas "transaccionalmente consistentes". Otro software comercial para acceder a archivos bloqueados en Windows incluye 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 por motivos de 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 fcntl. Aunque algunos tipos de bloqueos se pueden configurar para que sean obligatorios, los bloqueos de archivos en Unix son de aviso por defecto . 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 únicamente otros casilleros de archivos, no la E/S.

Se ofrecen dos tipos de cerraduras: cerraduras compartidas y cerraduras exclusivas. En el caso de fcntl, se pueden aplicar diferentes tipos de bloqueos a diferentes secciones (rangos de bytes) de un archivo o 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 ningún tipo de bloqueo. A diferencia de los bloqueos creados por fcntl, los creados por flockse conservan en forks, lo que los hace útiles para bifurcar servidores. Por lo tanto, es posible que más de un proceso mantenga 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 único proceso antes de duplicarse en un archivo 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 tanto, es posible que una base de datos tenga un concepto de "escrituras compartidas" frente a "escrituras exclusivas"; por ejemplo, se puede permitir cambiar un campo en el lugar mediante 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 real, en lugar del nombre del archivo. Esto es importante ya que Unix permite que varios nombres hagan referencia al mismo archivo. Junto con el bloqueo no obligatorio, esto genera una gran flexibilidad para acceder a archivos desde múltiples procesos. Por otro lado, el enfoque de bloqueo cooperativo puede generar problemas cuando un proceso escribe en un archivo sin obedecer los bloqueos de archivos establecidos por otros procesos.

Por este motivo, 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 que está bloqueada con un bloqueo exclusivo, o de escribir en una región que está 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 hoy se puede ver en los sistemas operativos Solaris , HP-UX y Linux. Sin embargo, no forma 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-o mand mediante el parámetro especial para el montaje del sistema de archivos ( mount(8)), pero rara vez se utiliza.

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

Problemas

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

Los bloqueos obligatorios no tienen ningún 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 hizo eso. [9]

Si flocklos bloqueos funcionan y cómo funcionan en los sistemas de archivos de red, como NFS , depende de la implementación. En los sistemas BSD , flocklas llamadas a un descriptor de archivo abierto en un archivo en una partición montada en NFS son exitosas y no operativas . En Linux anterior a 2.6.12, flocklas llamadas a archivos NFS actuarían solo localmente. El kernel 2.6.12 y superiores implementan flockllamadas en 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 bloquearse, lo que puede resultar contrario a la intuición.

Todos fcntl los bloqueos asociados con un archivo para un proceso determinado se eliminan cuando ese proceso cierra cualquier descriptor de archivo para ese archivo, incluso si nunca se solicitó un bloqueo para ese descriptor de archivo. Además, fcntllos bloqueos no los hereda un proceso hijo. La fcntlsemántica cercana es particularmente problemática para aplicaciones que llaman a bibliotecas de subrutinas que pueden acceder a archivos. Ninguno de estos "errores" ocurre al utilizar flockcerraduras de estilo real.

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

Problemas de E/S en buffer

Una fuente de error de bloqueo se produce cuando la E/S almacenada en búfer tiene búferes asignados en el espacio de trabajo local del usuario, en lugar de en un grupo de búfer del sistema operativo. fready fwritese usan comúnmente para realizar E/S almacenadas en el búfer, y una vez que se lee una sección de un archivo, otro intento de leer esa misma sección probablemente obtendrá los datos del búfer local. El problema es que otro usuario adjunto al mismo archivo tiene sus propios buffers locales y le sucede lo mismo. Un fwritedato obtenido del búfer freadno obtendrá los datos del archivo en sí y algún otro usuario podría haberlo cambiado. Ambos podrían usarse flockpara garantizar 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í, el usuario n.° 2 puede perder cualquier dato modificado por el usuario n.° 1 (sobrescrito). La mejor solución a este problema es usar E/S sin búfer ( ready write) con flock, lo que también significa usar lseeken lugar de fseeky ftell. Por supuesto, tendrá que realizar ajustes en los parámetros de la función y en los resultados obtenidos. En términos generales, la E/S almacenada en búfer no es segura cuando se utiliza con archivos compartidos.

En AmigaOS

En AmigaOS , se puede adquirir un bloqueo en un archivo (o directorio) usando la Lockfunción (en el archivo dos.library). Un bloqueo puede ser compartido (otros procesos pueden leer el archivo/directorio, pero no pueden modificarlo ni eliminarlo), o exclusivo para que solo el proceso que adquiere con éxito el bloqueo pueda acceder o modificar el objeto. El bloqueo está en todo el objeto y no en 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 finaliza el proceso.

bloquear archivos

Los scripts de Shell y otros programas suelen utilizar una estrategia similar al uso del bloqueo de archivos: creación de archivos de bloqueo , que son archivos cuyo contenido es irrelevante (aunque a menudo uno encontrará el identificador de proceso del titular del bloqueo en el archivo) y cuyo El ú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, por lo que no se aplica el uso de métodos para bloquear archivos. Por ejemplo, un archivo de bloqueo podría controlar 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 para garantizar que las operaciones sean atómicas . Para obtener un bloqueo, el proceso debe verificar que el archivo de bloqueo no existe y luego crearlo, mientras evita que otro proceso lo cree mientras tanto. Varios métodos para hacer esto incluyen:

Los archivos bloqueados a menudo se nombran con una tilde ( ~) antepuesta al nombre del archivo que están bloqueando, o un duplicado del nombre completo del archivo con el sufijo .LCK . Si están bloqueando un recurso que no es un archivo, es posible que se les nombre de manera más arbitraria.

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 (terminar 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 inapropiados o obsoletos, que a menudo surgen de situaciones anómalas, como procesos bloqueados o bloqueados, 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 para inspeccionar el estado de los bloqueos de archivos por proceso, por nombre de archivo o ambos. [ cita necesaria ]lockf

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. Los instaladores suelen utilizar este enfoque para reemplazar archivos del 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 del 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 desea cambiar el archivo realiza una operación de desbloqueo (también llamada pago), y hasta que se realiza una operación de registro (almacenamiento) o se revierte el bloqueo, nadie más puede desbloquear el archivo.

Ver 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. Documentos de Microsoft . contenido-sdk-de-windows. Corporación Microsoft . Consultado el 7 de noviembre de 2018 .
  3. ^ "Función LockFileEx". Kit de herramientas de desarrollo de software de Windows. Documentos de Microsoft . contenido-sdk-de-windows. Corporación Microsoft . Consultado el 7 de noviembre de 2018 .
  4. ^ "Función LockFileEx". Kit de herramientas de desarrollo de software de Windows. Documentos de Microsoft . contenido-sdk-de-windows. Corporación Microsoft . Consultado el 5 de julio de 2020 .
  5. ^ "Función LockFile". Kit de herramientas de desarrollo de software de Windows. Documentos de Microsoft . contenido-sdk-de-windows. Corporación Microsoft . Consultado el 5 de julio de 2020 .
  6. ^ "Bloqueo de archivos obligatorio 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 el servidor para NFS". cc731734(WS.10) . Consultado el 8 de octubre de 2011 .
  8. ^ Viega, Juan; Más desordenado, Matt (2003). "2.8 Bloquear archivos". Libro de recetas de programación segura para C y C++ (1ª ed.). Sabastopol, CA: O'Reilly Media. pag. 792.ISBN 978-0-596-00394-4. La 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, aunque exportan la interfaz utilizada por Linux y Solaris para admitirlos. En dichos sistemas, esta interfaz crea bloqueos de aviso. La compatibilidad con el bloqueo obligatorio 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 ed.). Profesional de Addison-Wesley. pag. 456.ISBN 978-0201433074.
  10. ^ "Mensajes de error que aparecen con frecuencia". nfs.sourceforge.net . Preguntas frecuentes sobre Linux NFS: D. Source Forge.
  11. ^ "Bloquee su secuencia de comandos (contra ejecución paralela)".

enlaces externos