¿Puede el método de archivo Java “canWrite()” admitir el bloqueo?

Question

Tengo una aplicación Java que monitorea una carpeta en busca de archivos XML entrantes.Cuando se detecta un archivo nuevo, necesito comprobar que el archivo no se está actualizando actualmente y está cerrado.Mi idea es usar Archivo.canWrite() para probar esto.¿Hay algún problema al hacer esto?¿Es esta una buena manera de comprobar que un archivo se ha escrito por completo?

Otras ideas que estoy lanzando son:

• Analice el archivo XML entrante y pruebe que la etiqueta de cierre esté allí.
• Compruebe el carácter EoF.

Simplemente no estoy seguro de que alguno de estos métodos pueda manejar todos los escenarios.

Answer 1

No, canWrite no es adecuado para este propósito.En general, se podrá escribir en el archivo incluso si otro proceso está escribiendo.

Necesita un protocolo de nivel superior para coordinar el bloqueo.Si planea usar este código en una sola plataforma, es posible que pueda usar Instalación FileLock de NIO.Pero lea atentamente la documentación y tenga en cuenta que, en muchas plataformas, el bloqueo es solo de asesoramiento.

Otro enfoque es hacer que un proceso escriba el archivo con un nombre que su proceso no reconocerá y luego cambiar el nombre del archivo a un nombre reconocible cuando se complete la escritura.En la mayoría de las plataformas, la operación de cambio de nombre es atómica si el origen y el destino son el mismo volumen del sistema de archivos.El cambio de nombre podría utilizar una extensión de archivo diferente o incluso mover el archivo de un directorio a otro (en el mismo volumen).

Dado que en este caso está trabajando exclusivamente con XML, buscar una etiqueta cercana funcionaría, pero no es infalible: ¿qué pasa si hay comentarios después del marcado final, o el escritor o simplemente no escribe XML válido?

Buscando el EOF no trabajar.Siempre habrá un EOF, incluso cuando el autor acaba de abrir el archivo y aún no ha escrito nada.Si esto no fuera así, lo más fácil sería permitir que el lector comience a analizar tan pronto como aparezca el archivo;simplemente se bloquearía hasta que el escritor cerrara el archivo.Pero el sistema de archivos no funciona de esta manera.Cada archivo tiene un final, incluso si algún proceso lo está moviendo actualmente.

Answer 2

Además, si realiza una verificación seguida de una escritura, entonces tiene una condición de carrera.El estado podría cambiar entre el cheque y la escritura.A veces es mejor intentar hacer lo que desea y manejar los errores con elegancia.quizás un mecanismo de reintento de n intentos con un mayor tiempo de retardo de retroceso.

O redefina su prueba.En este caso, tal vez podrías probar que el tamaño del archivo no haya cambiado durante un período de tiempo antes de procesarlo.

Otra opción es dividir el código en dos; podría tener otro hilo, tal vez una tarea de cuarzo, responsable de mover los archivos terminados a un directorio diferente que procesa su código principal.

Answer 3

Una cosa que parece funcionar en Windows es este: crear un objeto Archivo () que representa el archivo en cuestión (usando el constructor con nombre de archivo completo) - Cree un segundo objeto de archivo idéntico, de la misma manera.- Pruebe firstFile.renameTo (segundo archivo)

Este ejercicio ficticio de cambio de nombre parece tener éxito con archivos que no están abiertos para editarlos con otra aplicación (lo probé con Word), pero falla si están abiertos.

Y como el nombre de archivo nw = el nombre de archivo anterior, no crea ningún otro trabajo.

Answer 4

Hasta donde yo sé, no hay forma de saber si otro proceso tiene actualmente un identificador abierto para un archivo de Java.Una opción es utilizar el Bloqueo de archivos clase de nuevo io.Esto no es compatible con todas las plataformas, pero si los archivos son locales y el proceso de escritura del archivo coopera, esto debería funcionar para cualquier plataforma que admita bloqueos.

Answer 5

Si controlas tanto al lector como al escritor, entonces una posible técnica de bloqueo sería crear un bloqueo directorio (que suele ser una operación atómica) durante la duración del proceso de lectura y escritura.Si adopta este tipo de enfoque, debe gestionar la posible falla de un proceso que resulte en un directorio de bloqueo "colgado".

Como mencionó Cheekysoft, los archivos no son atómicos y no son adecuados para bloquearlos.

Si no controla al escritor (por ejemplo, si lo produce un demonio FTP), entonces la técnica de cambio de nombre o la técnica de retardo por período de tiempo son sus mejores opciones.