¿Por qué no puedo modificar los archivos en uso en Windows como puedo en Linux y OS X?
Cuando esté utilizando Linux y OS X, el sistema operativo no le impedirá eliminar un archivo actualmente en uso en Windows, pero 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??
La sesión de Preguntas y Respuestas de hoy nos llega por cortesía de SuperUser, una subdivisión de Stack Exchange, un grupo de sitios web de preguntas y respuestas impulsado por la comunidad..
La pregunta
El lector superusuario the.midget quiere saber por qué Linux y Windows tratan los archivos en uso de manera diferente:
Una de las cosas que me ha desconcertado desde que empecé a usar Linux es el hecho de que le permite cambiar el nombre de un archivo o incluso eliminarlo mientras se está leyendo. Un ejemplo es cómo accidentalmente intenté eliminar un video mientras se estaba reproduciendo. Lo logré, y me sorprendió 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 la escena y evitando que elimine cosas de manera gratuita en Windows como puede hacerlo en Linux??
La respuesta
Los contribuyentes de Superusuarios arrojaron algo de luz sobre la situación de the.midget. Asombrado escribe:
Cada vez que abre o ejecuta un archivo en Windows, Windows bloquea el archivo en su lugar (esto es una simplificación, pero generalmente es cierto). Un archivo que está bloqueado por un proceso no puede eliminarse hasta que ese proceso lo libere. Es por eso que cada vez que Windows tiene que actualizarse necesita un reinicio para que tenga efecto..
Por otro lado, los sistemas operativos similares a 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 se puede eliminar sin molestar a ningún programa que ya tenga el archivo abierto. Por lo tanto, puede eliminar un archivo mientras aún se está ejecutando o está en uso y continuará existiendo en el disco siempre y cuando algún proceso tenga un identificador abierto, aunque su entrada en la tabla de archivos haya desaparecido..
David Schwartz expande la idea y resalta cómo deberían ser las cosas idealmente y cómo son en la práctica:
De forma predeterminada, Windows es el bloqueo automático y obligatorio de archivos. UNIXes por defecto al bloqueo manual, cooperativo de archivos. En ambos casos, los valores predeterminados pueden ser anulados, pero en ambos casos generalmente no son anulados..
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 de C / C ++ no le proporciona ninguna manera de especificar cómo funcionará el bloqueo obligatorio, por lo que obtiene los valores predeterminados. El "modo compartido" predeterminado tiende a prohibir las operaciones "conflictivas". Si abre un archivo para escribir, se asume que las escrituras entran en conflicto, incluso si en realidad nunca escribe en el archivo. Lo mismo para los nombres.
Y, aquí es donde empeora. Aparte de abrirse para leer o escribir, la API de C / C ++ no proporciona ninguna manera de especificar qué pretende hacer con el archivo. Así que la API debe 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 conflictiva, sino que simplemente estaba abriendo el archivo para otro propósito.
Entonces, si el código utiliza la API C / C ++, o la API nativa sin pensar específicamente en estos problemas, terminarán impidiendo el conjunto máximo de operaciones posibles para cada archivo que abren y no pueden abrir un archivo a menos que se realicen todas las operaciones posibles. podría realizar en él una vez abierto no está en 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 de apertura con prudencia y manejo de los casos de falla. El método UNIX, sin embargo, funciona mejor si el código no se molesta en pensar en 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 el conflicto se abre bien. Así que el resultado neto es un poco desordenado..
Ahí lo tienen: dos enfoques diferentes para el manejo de archivos dan dos resultados diferentes.
¿Tienes algo que agregar a la explicación? Apague el sonido en los comentarios. ¿Quieres leer más respuestas de otros usuarios de Stack Exchange con experiencia en tecnología? Echa un vistazo a la discusión completa aquí.
