2009-02-13 32 views
17

El bloqueo de archivos UNIX es dead-easy: El sistema operativo asume que usted sabe lo que está haciendo y le permite hacer lo que desee:¿Cómo hago que el bloqueo de archivos de Windows sea más parecido al bloqueo de archivos UNIX?

Por ejemplo, si intenta eliminar un archivo que otro proceso ha abierto, el sistema operativo generalmente te permitirá hacerlo. El proceso original aún conserva sus identificadores de archivo hasta que finaliza, momento en el que el sistema de archivos reiniciará silenciosamente los recursos de disco. Sin problemas, así es como me gusta.

Diferentes cosas en Windows: si trato de eliminar un archivo que está usando otro proceso, aparece un error del sistema operativo. El archivo es intocable hasta que el proceso original libera su bloqueo en el archivo. Eso fue genial en los días de un solo usuario de MS-DOS cuando era probable que cualquier proceso de bloqueo estuviera en la misma computadora que contenía los archivos; sin embargo, en una red es una pesadilla:

Considere lo que sucede cuando se cuelga un proceso mientras escribe en un archivo compartido en un servidor de archivos de Windows. Antes de que el archivo pueda eliminarse, debemos ubicar la computadora e identificar el proceso en esa computadora que originalmente abrió el archivo. Solo entonces podemos matar el proceso y eliminar nuestro archivo no deseado.

¡Qué molestia!

¿Hay alguna manera de mejorar esto? Lo que quiero es que el bloqueo de archivos en Windows se comporte como un bloqueo de archivos en UNIX. Quiero que el sistema operativo me deje hacer lo que quiero porque estoy a cargo y sé lo que estoy haciendo ...

... ¿se puede hacer?

+0

Lo dudo seriamente. El comportamiento de Unix donde un programa puede seguir accediendo a un archivo borrado hasta que lo cierra es profundo en el sistema operativo. –

+0

Para mí, bloqueo de archivos significa usar fcntl y LockFileEx. Estás preguntando si tienes permiso para abrir o eliminar un archivo. –

Respuesta

8

Según MSDN puede especificar a CreateFile() 3er parámetro (dwSharedMode) compartida indicador de modalidad de la que FILE_SHARE_DELETE:

permite que las operaciones posteriores abiertos en un archivo o dispositivo a petición de supresión de acceso.

De lo contrario, otros procesos no pueden abrir el archivo o el dispositivo si solicitan acceso de eliminación.

Si no se especifica este indicador, pero el archivo o dispositivo se ha abierto para eliminar el acceso, la función falla.

Nota El acceso de eliminación permite operaciones de eliminación y cambio de nombre.

http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx

Así que si estás pueden controlar las aplicaciones que pueden utilizar esta bandera.

+0

Esto no es una panacea que proporciona un enlace similar a Unix. Simplemente permite otras referencias de objetos de archivo para cambiar el nombre del archivo o establecer/deshacer su disposición de eliminación. Establecer la disposición de eliminación no desvincula un archivo. La rutina de limpieza del controlador del sistema de archivos solo desvincula un archivo cuando se cierra el último identificador. Donde esto difiere notablemente de Unix es cuando intentas eliminar un directorio que contiene archivos que están en uso. Suponiendo que los archivos están abiertos con el uso compartido de eliminación, una solución alternativa es cambiarles el nombre a un directorio temporal en el mismo volumen. – eryksun

7

No. Windows está diseñado para el "usuario promedio", es decir, las personas que no entienden nada acerca de una computadora. Por lo tanto, el sistema operativo intenta ser inteligente para evitar PEBKAC s. Para citar a Bill Gates: "No hay problemas con Windows que cualquier número de personas quiera reparar". Por supuesto, él sabe que el 99.9999% de todos los usuarios de Windows no pueden decir si el programa simplemente hizo algo extraño debido a ellos o al tipo que lo escribió.

Unix fue diseñado cuando el mundo era más simple y cualquier persona lo suficientemente cerca de una computadora para tocarlo, probablemente sabía cómo armarlo de arena sucia. Por lo tanto, el sistema operativo generalmente le permite hacer lo que desea porque supone que usted conoce mejor (y si no lo hizo, lo hará la próxima vez).

Respuesta técnica: Unix asigna un "i-nodes" si crea un archivo. Los I-nodes se pueden compartir entre procesos.Si dos procesos crean el mismo archivo (es decir, dos procesos llaman a create() con la misma ruta), usted termina con dos i-nodes. Esto es por diseño. Además, permite una característica de seguridad de fantasía: Se pueden crear archivos que nadie puede abrir, pero sí mismo:

  1. Abrir un archivo
  2. Suprimirlo (pero mantener el identificador de archivo)
  3. Utilice el archivo de la forma que como
  4. Cierre el archivo

Después del paso # 2, el único proceso en el universo que puede tener acceso al archivo es el que lo creó (a menos que desee leer el bloque de disco duro por bloque). El sistema operativo mantendrá los datos vivos hasta que cierre el archivo o su proceso fallezca (en ese momento Unix lo hará después).

Este diseño es la base de todos los sistemas de archivos Unix. El sistema de archivos de Windows NTFS funciona de la misma manera pero la API de alto nivel es diferente. Muchas aplicaciones abren archivos en modo exclusivo (lo que impide que cualquiera, incluso los programas de copia de seguridad) lean el archivo. Esto es cierto incluso para aplicaciones que solo muestran información como lectores de PDF.

Eso significa que tendrá que reparar todas las aplicaciones de Windows para lograr el efecto deseado. Si tiene acceso a la fuente, puede crear un archivo en un modo compartido. Eso permitiría que otros procesos accedan a él al mismo tiempo, pero luego, deberá verificar antes de cada lectura/escritura si el archivo aún existe, si alguien ha realizado cambios, etc.

+1

No creo que así sea como funciona. No puedes tener dos inodos para el mismo archivo. Diferentes inodos, diferentes archivos. Además, puedes leer cualquier archivo abierto que quieras con procfs. –

+0

mismo archivo => misma ruta. Fijo. Además, ¿qué quieres decir con tu comentario sobre procfs? –

+0

Seguramente lo que está haciendo el "usuario promedio" no tiene nada que ver con la semántica de archivos de bajo nivel. Para mí, esto es solo un problema para los programadores. – MarkR

1

Eso realmente no ayuda si el proceso colgado todavía tiene el mango abierto. No liberará los recursos hasta que ese proceso bloqueado libere el controlador. Pero de todos modos, en Windows es posible forzar el cierre de un archivo desde un proceso que lo está usando. Process Explorer de sysinternals.com le permitirá ver y cerrar identificadores que un proceso ha abierto.

+1

procexp es ideal para sysadmin, pero no para el desarrollador: ¡quiero que mis cosas se ejecuten sin supervisión! –

3

Tenga en cuenta que Process Explorer permite forzar el cierre de los identificadores de archivo (para los procesos locales en el cuadro en el que se está ejecutando) a través de Handle -> Cerrar Handle.

Unlocker pretende hacer mucho más, y proporciona una útil lista de otras herramientas.

También borrar al reiniciar es una opción (aunque esto suena como que no es lo que quiere)

Cuestiones relacionadas