Me di cuenta cuando un archivo se ejecuta en Windows (.exe o .dll), está bloqueado y no se puede eliminar, mover o modificar.Bloqueo de ejecución de archivos: Windows sí, Linux no. ¿Por qué?
Linux, por otro lado, no bloquea los archivos de ejecución y puede eliminarlos, moverlos o modificarlos.
¿Por qué Windows se bloquea cuando Linux no? ¿Hay alguna ventaja para bloquear?
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 en el bloqueo? 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 los sistemas de archivos de la ventana.
"Windows" en este contexto es la línea de Windows NT. Esto fue diseñado como un sucesor multiusuario para un usuario de Windows 3.11. Compare con Unix, que es el sucesor de usuario único para Multics. – MSalters
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 controlador 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.
woah - ¡casi palabra por palabra lo que estaba a punto de escribir antes de que apareciera diciendo que había nuevas respuestas! – Mez
¿Qué mecanismo utiliza Windows para contar la cantidad de procesos que han bloqueado el archivo :)? – xtofl
Windows usa "Handles", aunque la semántica de lo que "parece" un archivo bloqueado es muy diferente. –
Por lo que sé, Linux hace bloquear ejecutables cuando están en ejecución, 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 Unix utilizan esta manera de pensar sobre el sistema de archivos todo el tiempo, crean un archivo temporal, lo abren, eliminan el nombre. Su archivo aún existe, pero el nombre se libera para que otros lo usen y nadie más puede verlo.
"todo el tiempo"? ¿Algún ejemplo? – Mez
Pregunta a google sobre "archivo temporal seguro de Unix" y encontrarás suficientes descripciones de la técnica para demostrar que es conocida y de uso común. Si bien no tengo ningún ejemplo específico para dar, me atrevo a decir que cualquier aplicación consciente de la seguridad que use archivos temporales lo hace. –
variantes NT tienen los
openfiles comando
, que mostrará los procesos que tienen asas en los archivos. Sin embargo, requiere habilitar la bandera global del sistema 'mantener la lista de objetos'
openfiles/local /?
le indica cómo hacerlo, y también que se incurre en una penalización de rendimiento al hacerlo.
Creo que eres demasiado absoluto sobre Windows. Normalmente, no asigna espacio de intercambio para la parte del código de un ejecutable. En su lugar, mantiene un bloqueo en las DLL & excutable. 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.
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 normalmente se hace automáticamente por su sistema de administració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 iniciando sesión en ese archivo que vuelva a abrir el archivo, que mantendrá la referencia, y se preguntará por qué su disco no tiene mucho más espacio libre de repente.
También puede utilizar este truco en 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á.
Programas como lsof y fuser (o simplemente hurgando en/proc // fd) pueden mostrarle qué procesos tienen archivos abiertos que ya no tienen un nombre.
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: así no necesita saber qué código en qué versión se utiliza por cual 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.
Así que 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 alrededor de 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 tal, 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 a read all hard links for a given file y tal.
Además, es posible que simplemente quiera echar un vistazo a las estructuras utilizadas para describir un archivo, p. Ext4 en comparación con los 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.
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 el Wikipedia.
Hay una utilidad llamada [WhoLockMe] (http://www.dr-hoiby.com/WhoLockMe/index.php) que agrega una entrada de menú al menú contextual en el explorador que puede mostrar el proceso (es) bloqueando un archivo dado. Extremadamente útil cuando obtienes errores de bloqueo de archivos extraños. Editar: Sé que esto no responde a la pregunta, pero pensé que era lo suficientemente útil en el contexto para justificar una respuesta por separado (como opuesto a un simple comentario). – JesperE