Bloquear archivos de ejecución: Windows sí, Linux no. ¿Por qué?
operating-system filesystems (8)
Creo que Linux / Unix no usa la misma mecánica de bloqueo porque están construidos desde cero como un sistema multiusuario, lo que podría suponer la posibilidad de que varios usuarios usen el mismo archivo, incluso para diferentes propósitos.
¿Hay alguna ventaja para bloquear? Bueno, posiblemente podría reducir la cantidad de indicadores que el sistema operativo tendría que gestionar, pero ahora los días la cantidad de ahorros es bastante insignificante. La mayor ventaja que puedo pensar para bloquear es la siguiente: guarda una ambigüedad visible para el usuario. Si el usuario a está ejecutando un archivo binario, y el usuario b lo elimina, entonces el archivo real debe permanecer hasta que el proceso del usuario A finalice. Sin embargo, si el usuario B u otros usuarios lo buscan en el sistema de archivos, no podrán encontrarlo, pero seguirán ocupando espacio. No es realmente una gran preocupación para mí.
Creo que en gran medida es más una cuestión de compatibilidad con versiones anteriores de los sistemas de archivos de Windows.
Noté que cuando un archivo se ejecuta en Windows (.exe o .dll), está bloqueado y no se puede eliminar, mover ni modificar.
Linux, por otro lado, no bloquea la ejecución de archivos y puede eliminarlos, moverlos o modificarlos.
¿Por qué Windows se bloquea cuando Linux no funciona? ¿Hay alguna ventaja para bloquear?
Creo que eres demasiado absoluto con respecto a Windows. Normalmente, no asigna espacio de intercambio para la parte del código de un ejecutable. En cambio, mantiene un bloqueo en los archivos ejecutables y las DLL. Si las páginas de códigos descartadas se necesitan nuevamente, simplemente se vuelven a cargar. Pero con / SWAPRUN, estas páginas se mantienen en intercambio. Esto se usa para ejecutables en CD o unidades de red. Por lo tanto, Windows no necesita bloquear estos archivos.
Para .NET, mira Shadow Copy .
Hasta donde yo sé, Linux bloquea los ejecutables cuando se están ejecutando, sin embargo, bloquea el inode . Esto significa que puede eliminar el "archivo", pero el inodo todavía está en el sistema de archivos, intacto y todo lo que realmente borró es un enlace.
Los programas de Unix utilizan esta forma de pensar sobre el sistema de archivos todo el tiempo, crean un archivo temporal, lo abren y eliminan el nombre. Su archivo aún existe, pero el nombre se libera para que otros lo usen y nadie más puede verlo.
Las variantes NT tienen
abrir archivos
comando, que mostrará qué procesos tienen identificadores en qué archivos. Sin embargo, requiere habilitar la bandera global del sistema ''mantener la lista de objetos''
archivos abiertos / locales /?
le dice cómo hacer esto, y también que se incurre en una penalización de rendimiento al hacerlo.
Linux bloquea los archivos. Si intentas sobrescribir un archivo que se está ejecutando, obtendrás "ETXTBUSY" (archivo de texto ocupado). Sin embargo, puede eliminar el archivo y el kernel eliminará el archivo cuando se elimine la última referencia. (Si la máquina no se apagó limpiamente, estos archivos son la causa del mensaje "El inodo eliminado tenía cero tiempo de inactividad" cuando se verifica el sistema de archivos, no se eliminaron completamente, porque un proceso en ejecución tenía una referencia a ellos, y ahora lo son)
Esto tiene algunas ventajas importantes, puede actualizar un proceso que se está ejecutando, eliminando el ejecutable, reemplazándolo y luego reiniciando el proceso. Incluso init puede actualizarse así, reemplazar el ejecutable y enviar una señal, y se volverá a ejecutar (), sin necesidad de reiniciar. (Esto es hecho normalmente por su sistema de gestión de paquetes como parte de su actualización)
En Windows, reemplazar un archivo que está en uso parece ser una gran molestia, generalmente requiere un reinicio para asegurarse de que no se estén ejecutando procesos.
Puede haber algunos problemas, como si tiene un archivo de registro extremadamente grande, y lo quita, pero se olvida de indicarle al proceso que estaba ingresando en ese archivo que vuelva a abrir el archivo, que mantendrá la referencia, y se preguntará ¿Por qué su disco no de repente tiene mucho más espacio libre?
También puede usar este truco bajo Linux para archivos temporales. abra el archivo, elimínelo y luego continúe usando el archivo. Cuando finaliza su proceso (sin importar la razón, incluso el corte de energía), el archivo se eliminará.
Los programas como lsof y fuser (o simplemente hurgando en / proc // fd) pueden mostrarle qué procesos tienen archivos abiertos que ya no tienen un nombre.
Linux tiene un mecanismo de recuento de referencias, por lo que puede eliminar el archivo mientras se está ejecutando, y continuará existiendo siempre que algún proceso (que lo abrió anteriormente) tenga un control abierto para él. La entrada de directorio para el archivo se elimina cuando la elimina, por lo que ya no se puede abrir, pero los procesos que ya usan este archivo aún pueden usarla. Una vez que todos los procesos que usan este archivo finalizan, el archivo se elimina automáticamente.
Windows no tiene esta capacidad, por lo que se ve obligado a bloquear el archivo hasta que todos los procesos que se ejecutan desde allí hayan finalizado.
Creo que el comportamiento de Linux es preferible. Probablemente haya algunas razones arquitectónicas profundas, pero el motivo principal (y simple) que considero más convincente es que en Windows, a veces no puede eliminar un archivo, no tiene idea de por qué, y todo lo que sabe es que algún proceso lo mantiene en utilizar. En Linux nunca sucede.
Los ejecutables se asignan progresivamente a la memoria cuando se ejecutan. Lo que eso significa es que porciones del ejecutable se cargan según sea necesario. Si el archivo se intercambia antes de que se mapeen todas las secciones, podría causar una gran inestabilidad.
Si el código ejecutado en un archivo debe estar bloqueado o no, es una decisión de diseño y MS simplemente decidió bloquearlo, porque tiene claras ventajas en la práctica: de esa manera no necesita saber qué código en qué versión utiliza cada aplicación. Este es un problema importante con el comportamiento predeterminado de Linux, que simplemente es ignorado por la mayoría de las personas. Si se reemplazan las bibliotecas de todo el sistema, no se puede saber fácilmente qué aplicaciones usan el código de dichas bibliotecas, la mayoría de las veces lo mejor que se puede obtener es que el administrador de paquetes conoce algunos usuarios de esas bibliotecas y las reinicia. Pero eso solo funciona para cosas generales y bien conocidas como tal vez Postgres y sus libs o tal. Los escenarios más interesantes son si desarrolla su propia aplicación contra algunas librerías de terceros y esas son reemplazadas, porque la mayoría de las veces el administrador de paquetes simplemente no conoce su aplicación. Y eso no es solo un problema de código C nativo o similar, puede ocurrir con casi todo: simplemente use httpd con mod_perl y algunas bibliotecas Perl instaladas usando un administrador de paquetes y deje que el administrador de paquetes actualice esas bibliotecas Perl por cualquier motivo. No reiniciará su httpd, simplemente porque no conoce las dependencias. Hay muchos ejemplos como este, simplemente porque cualquier archivo puede contener código en uso en la memoria en cualquier tiempo de ejecución, piense en Java, Python y todas esas cosas.
Entonces, hay una buena razón para tener la opinión de que bloquear archivos por defecto puede ser una buena opción. Sin embargo, no necesitas estar de acuerdo con esas razones.
Entonces, ¿qué hizo MS? Simplemente crearon una API que le da a la aplicación que realiza la llamada la oportunidad de decidir si los archivos deben estar bloqueados o no, pero decidieron que el valor predeterminado de esta API es proporcionar un bloqueo exclusivo a la primera aplicación de llamada. Eche un vistazo a la API en torno a CreateFile y su argumento dwShareMode . Esa es la razón por la que es posible que no pueda eliminar archivos en uso por alguna aplicación, simplemente no le importa su caso de uso, utilizó los valores predeterminados y, por lo tanto, Windows obtuvo un bloqueo exclusivo para un archivo.
No crea en las personas que le dicen algo acerca de que Windows no utiliza el recuento de referencias en HANDLEs o no admite Hardlinks o cosas así, eso es completamente incorrecto. Casi todas las API que usan HANDLEs documentan su comportamiento con respecto al conteo de ref y usted puede leer fácilmente en casi cualquier artículo sobre NTFS que de hecho soporta Hardlinks y siempre lo hizo, ya que Windows Vista también tiene soporte para Symlinks y el soporte para Hardlinks ha sido mejorado al proporcionar API para leer todos los enlaces duros para un archivo determinado y tal.
Además, es posible que simplemente desee echar un vistazo a las estructuras utilizadas para describir un archivo en, por ejemplo, Ext4 comparación con las de NTFS , que tienen mucho en común. Ambos funcionan con el concepto de extensiones, que separa los datos de atributos como el nombre de archivo, y los inodos son simplemente un nombre más para un concepto anterior, pero similar. Incluso Wikipedia enumera ambos sistemas de archivos en su article .
En realidad, hay mucho FUD alrededor del bloqueo de archivos en Windows en comparación con otros sistemas operativos en la red, al igual que sobre la desfragmentación. ;-) Parte de este FUD se puede descartar simplemente leyendo un poco en la Wikipedia .