17Aug
Cuando está utilizando Linux y OS X, el sistema operativo no le impedirá borrar un archivo actualmente en uso pero en Windows se le prohibirá expresamente hacerlo.¿Lo que da?¿Por qué puede editar y eliminar archivos en uso en sistemas derivados de Unix pero no en Windows?
Pregunta de hoy &La sesión de respuesta nos llega por cortesía de SuperUser, una subdivisión de Stack Exchange, una agrupación de sitios web Q & A dirigida por la comunidad.
The Question
SuperUser reader the.midget quiere saber por qué Linux y Windows tratan los archivos en uso de forma diferente:
Una de las cosas que me ha dejado perplejo desde que comencé a usar Linux es el hecho de que le permite cambiar el nombre deun archivo o incluso eliminarlo mientras se está leyendo. Un ejemplo es cómo intenté accidentalmente eliminar un video mientras se estaba reproduciendo. Tuve éxito, y me sorprendí al saber que puede cambiar casi cualquier cosa en un archivo sin importar si se está utilizando en este momento o no.
Entonces, ¿qué está sucediendo detrás de escena y evitando que borre cosas en Windows como lo hace en Linux?
Los contribuidores Respuesta
SuperUser arrojan algo de luz sobre la situación para. midget. Escrituras asombradas:
Cada vez que abre o ejecuta un archivo en Windows, Windows bloquea el archivo en su lugar( esto es una simplificación, pero por lo general es verdadero.) Un archivo que está bloqueado por un proceso no se puede eliminar hasta que el proceso lo libere. Esta es la razón por la cual, siempre que Windows tiene que actualizarse a sí mismo, necesita reiniciarse para que surta efecto.
Por otro lado, los sistemas operativos tipo Unix como Linux y Mac OS X no bloquean el archivo sino los sectores de disco subyacentes. Esto puede parecer una diferenciación trivial, pero significa que el registro del archivo en la tabla de contenido del sistema de archivos puede eliminarse sin alterar ningún programa que ya tenga el archivo abierto. Por lo tanto, puede eliminar un archivo mientras se está ejecutando o en uso y continuará existiendo en el disco, siempre y cuando algún proceso tenga un controlador abierto aunque su entrada en la tabla de archivos haya desaparecido.
David Schwartz amplía la idea y destaca cómo deberían ser las cosas de manera ideal y cómo funcionan en la práctica:
Windows se establece de forma predeterminada en el bloqueo de archivos automático y obligatorio. UNIXes de forma predeterminada a bloqueo de archivos manual y cooperativo. En ambos casos, los valores predeterminados pueden ser anulados, pero en ambos casos generalmente no lo son.
Una gran cantidad de código antiguo de Windows utiliza la API C / C ++( funciones como fopen) en lugar de la API nativa( funciones como CreateFile).La API C / C ++ no le permite especificar cómo funcionará el bloqueo obligatorio, por lo que obtiene los valores predeterminados. El "modo compartir" predeterminado tiende a prohibir las operaciones "conflictivas".Si abre un archivo para escribir, se supone que las escrituras entran en conflicto, incluso si nunca escribe en el archivo. Lo mismo para cambiar el nombre.
Y aquí es donde empeora. Además de abrir para lectura o escritura, la API de C / C ++ no proporciona ninguna forma de especificar lo que tiene la intención de hacer con el archivo. Entonces, la API tiene que asumir que va a realizar cualquier operación legal. Dado que el bloqueo es obligatorio, se rechazará una apertura que permita una operación conflictiva, incluso si el código nunca tuvo la intención de realizar la operación en conflicto, sino que solo estaba abriendo el archivo para otro fin.
Entonces, si el código usa la API C / C ++, o usa la API nativa sin pensar específicamente en estos problemas, terminarán previniendo el máximo conjunto de operaciones posibles para cada archivo que abran y no pudiendo abrir un archivo a menos que todas las operaciones posiblesPodrían funcionar en él una vez abierto no tiene ningún conflicto.
En mi opinión, el método de Windows funcionaría mucho mejor que el método UNIX si cada programa eligiera sus modos de compartir y modos abiertos sabiamente y manejara casos de fallas. El método UNIX, sin embargo, funciona mejor si el código no se molesta en pensar sobre estos problemas. Desafortunadamente, la API básica de C / C ++ no se correlaciona bien con la API de archivos de Windows de una manera que maneja los modos de compartir y las entradas conflictivas se abren bien. Entonces el resultado neto es un poco desordenado.
Ahí lo tiene: dos enfoques diferentes para el manejo de archivos producen dos resultados diferentes.
¿Tiene algo que agregar a la explicación? Suena apagado en los comentarios.¿Desea leer más respuestas de otros usuarios de Stack Exchange expertos en tecnología? Mira el hilo de discusión completo aquí.
