Détecter un fichier en cours de modification

Bonjour la communauté,

Je développe actuellement un module en java qui permet de récupérer des fichiers (image/texte) et de les convertir en ressources.

Le principe :
Il y a un répertoire dépôt dans lequel les utilisateurs ajoutent leurs fichier, le programme doit être capable de détecter si un nouveau fichier à été déposé, le récupérer et le convertir en ressource (pour faire simple).

Mon problème :
J'aimerai anticiper un cas d'erreur, si mon programme détecte un nouveau fichier, j'aimerai qu'il soit capable de déterminer si le fichier est actuellement en cours de modification (ce qui peut arriver avec un .txt par exemple). Seulement après une petite matinée de recherche je ne trouve pas vraiment de solution viable. J'utilise l'API NIO 2 et WatchService pour développer ce module mais malgré une grosse lecture des explications de JMDoudoux (mon héro ce gars la) et de la plupart des topics de développez.com à ce sujet je n'ai pas trouvé de solution à mon problème.

Est-ce que quelqu'un par ici aurait un début de solution à proposer ?

Merci !

Salut,

La notion "en cours de modification" est très relative. Un fichier peut être en cours d'écriture : un flux a été ouvert, tous les octets n'ont pas été encore vidés dans le flux, ou écrits physiquement (l'état qu'on peut connaître d'un fichier n'est pas forcément celui qu'il a réellement à ce moment), et le flux n'est pas fermé. Le système peut prévenir une écriture concurrent, mais pas forcément une lecture concurrente d'un fichier en cours d'écriture. Et un fichier peut être en cours de modification par un utilisateur sans être ouvert, ou sans être verrouillé quand c'est supporté, donc sans être connu du système de fichier comme étant "en cours de modification" au sens qu'un utilisateur est en train de travaille dessus (donc pas forcément qu'il y ait un process qui est en train d'écrire dedans).

Personnellement, j'ai mis en place des systèmes qui en pratique fonctionnaient assez bien parce que statistiquement, il était peu probable de tomber sur un cas problématique (y compris sur des spools dans lesquels des systèmes automatisés déversaient des fichiers, genre fil de dépêches par exemple (plus ou moins ancêtre des files RSS). Par exemple, pour uploader automatiquement un fichier InDesign ouvert dans Adobe InDesign, donc exclusivement, par une commande relayer via HTTP vers mon application Java depuis un plug-in InDesign, je copiais le fichier le plus rapidement possible, juste un transfert vers un fichier temporaire vers une file physique, et je faisais le traitement sur la copie. Statistiquement, deux sauvegardes successives étaient très rares : dans la mesure où chaque sauvegarde invalidait fonctionnellement le précédent upload, il me suffisait de comparer la taille et la date des deux fichiers (la copie été crée avec la même date que l'origine) pour déterminer que le fichier avait été resauvegardé entre le début et la fin de la copie et je recommençais (j'étais couvert fonctionnellement par un état de retour dans le client qui limitait les sauvegardes successives intempestives, mais il faut aussi compter qu'un utilisateur normal ne sauvegarde que peu souvent relativement au temps qu'il faut pour copier un fichier).

Pour les spools (ton cas d'ailleurs), je vérifiais à intervalle régulier si le fichier changeait de taille et/ou de date. En te faisant une petite classe/méthode qui encapsule une petite boucle qui vérifie toutes les 100 ms par exemple tu peux un système simple qui fait ça. Attention, pour avoir mis en pratique ce système il y'a une quinzaine d'années, il ne fonctionnait pas sur certains types de montage CIFS/NFS (Mac en particulier), à cause de systèms de cache (il a fallut être en place des systèmes de touch sur les machines distantes pour forcer la mise à jour du cache), mais en local, ça fonctionnait très bien pour les fichiers en cours d'écriture.

Cependant, des fichiers peuvent être "ouverts" (avec un verrou exclusif posé par une application) sans être nécessairement en cours d'écriture. C'est plutôt rare pour un fichier txt, mais pourquoi pas. S'il y a un verrou exclusif, la bibliothèque Apache Commons fournit la méthode org.apache.commons.io.FileUtils.touch(File), qui tente simplement d'ouvrir un FileWriter sur le fichier.

Enfin, des fichiers peuvent être ouverts sans pourtant être verrouillé (un fichier texte dans Sublime Text par exemple) : le souci c'est que le fichier peut être ouvert en écriture après que tu commences à le lire. Tu peux utiliser java.nio.channels.FileLock mais il faut savoir que tous les systèmes ne le supportent pas obligatoirement. FileLock peut être utilisé également dans le cas précédent (à la place de, ou en même temps, la multiplication des systèmes permettant de réduire le nombres de cas problématiques).

Il y a probablement d'autres stratégies, mais globalement tu peux voir qu'il n'y a pas vraiment de solution simple qui fonctionne à 100% sur tous les systèmes, et encore moins dans des environnements hybrides, mais un ensemble de petites solutions qui contribuent ensemble à ce que ça fonctionne la plupart du temps.

D'accord c'est donc bien plus compliqué que ce que j'imaginais, je pensais trouver une méthode toute prête dans l'API qui permettait ça au départ.

Du coup je vais opter pour une solution provenant de l'API NIO 2, avec getLastModifiedTime() on peut obtenir la date de la dernière modification, cette méthode étant compatible avec java.time je pourrais probablement créer une variable qui prend 1 min de plus que la date récupérée et récupérer le fichier une fois cette date atteinte, ça laissera une minute au système pour terminer sa modif ce qui devrait être suffisant je pense.

Sinon j'essaierai de récupérer la date de réception de l’événement MODIFY que me renverra mon WatchKey et tenterai d'utiliser une technique similaire pour laisser le temps au système de terminer son action.

Je vais approfondir encore mes recherches, ça fait un peu moins de 6 mois que je développe en Java alors c'est pas encore tout à fait naturel pour moi de trouver des solution à mes problèmes.

Merci en tout cas !