0
votes

Détecter les fichiers modifiés dans un répertoire (Java 8) de Digest ou CheckSum

Je recherche un moyen simple de détecter si les fichiers ont changé dans un répertoire entre redémarrages pour éviter une synchronisation inutile. Quel serait le moyen le plus simple de le faire dans les bibliothèques Java 8? Devrais-je xor le MD5 Digest de chaque fichier ou xor les checksums de chaque fichier?

guichet automatique, nous n'avons pas besoin de gérer des sous-répertoires.

Nous ne devrions également pas utiliser un événement de système d'exploitation pour détecter ce changement car la méthode à détecter ne sera appelée qu'au démarrage. Le nombre de fichiers dans le répertoire peut changer entre différentes versions de l'application, mais ces fichiers ne changeront généralement pas entre les redémarrages.

Ceci ressemble à un poste pertinent: https://crypto.stackexchange.com/questions/1368/is-it-a-good-dea-a-utilisation-bitwitwitwitwitwitwit-fof-md5-sums


5 commentaires

Cela vous aiderait-t-il? docs.oracle.com/javase/tatuly/essential/ io / notificati on.html


@Lyjuiiedwinson Merci mais je ne cherche pas spécifiquement à détecter les modifications de fichiers par des événements OS car cette routine ne sera déclenchée qu'au démarrage du système.


Qu'est-ce que cela signifie exactement par "pour éviter la synchronisation inutile"? Êtes-vous en train de refléter des fichiers dans un autre répertoire? Ensuite, peut-être que vous devriez mieux utiliser RSYNC au lieu de rouler le vôtre.


@Axel Il est spécifique à notre application, lorsque ces fichiers sont modifiés, nous devons resynériser notre contrôleur à notre base de données et ce processus prend un moment. Fondamentalement, il existe un fichier volumineux qui est refacturé dans des fichiers XML plus petits via des instructions xinclude et je souhaite désormais détecter de manière dynamique si ces fichiers plus petits ont été modifiés au lieu de la maintenance d'une liste de fichiers dans le code. Nous venons auparavant, nous venons de mettre en cache une copie du MD5 de notre grand fichier.


@simgineer Vous devez lire attentivement la notification de fichier, car elle a non seulement tiré au démarrage du système.


3 Réponses :


0
votes

est l'heure modifiée du fichier utile dans votre situation? MD5SUM est un moyen de préciser pour certaines situations.


1 commentaires

Je pense que nous préférons les checksums ou la digère à des horodatages au cas où le temps de systèmes n'est pas correctement défini correctement.



2
votes

Cela dépend de ce que vous entendez par "SIMPLE".

D'une part, vous pouvez utiliser le fichier horodatage. Mais le problème est que les horodatages peuvent être trompeurs:

  • vérifie en fonction des horaires pourraient être affectés par des problèmes d'horloge. (Cela dépend des horloges impliquées et sur la gestion des horloges.)

  • Il est possible pour le fichier horodatage d'être réinitialisé (par exemple par l'utilisateur "root"), ce qui semble apparaître qu'un fichier n'a pas changé.

  • Il est trivial de modifier un horodatage de fichier "modifié" sans changer le fichier; par exemple. Touchez .

    D'autre part, si vous utilisez des checksums, vous avez d'autres problèmes:

    • Computing Un checksum de fichier implique la lecture de l'ensemble du fichier. (Une somme de contrôle partielle n'est pas suffisante pour détecter les changements, en général.) Certains algorithmes de contrôle sont également relativement coûteux.

    • Vous devez également savoir ce que la liste de contrôle EM> Précédent du fichier était. Cela signifie que vous avez besoin d'un moyen / endroit pour la stocker. Cela pourrait être juste un autre fichier, mais vous avez ensuite besoin d'une infrastructure pour mettre à jour ce fichier (fiable) dans le cadre de la procédure de synchronisation.

    • Les checks multiples xors ont le problème que vous ne savez que quels fichiers ont changé. Si un fichier change, vous devez les synchroniser tous.

    • Il est théoriquement possible pour un fichier de changement et la somme de contrôle MD5 pour être la même: probabilité 1 sur 2 ^ 128. Vous pouvez probablement escompter ceci ... à moins que le vôtre est une application critique de sécurité. (Notez que les attaques de collision MD5 sont pratiques dans certains contextes ; voir HTTPS: // en.wikipedia.org/wiki/collision_attack )


      L'autre chose est que je soupçonne que vous essayez de résoudre un problème résolu. Par exemple, l'utilitaire Linux / Unix RSYNC a des options permettant d'utiliser des checksums horodaques ou (MD5) pour décider quels fichiers doivent être synchronisés.

      Vous n'avez pas besoin de tout implémenter vous-même (en Java).

      en réponse à votre "Nous n'avons pas accès à l'ancien arborescence de fichiers" il y a une solution facile à cela. Chaque fois que vous redémarrez:

      1. Copiez l'arborescence de fichiers
      2. Comparez les fichiers actuels par rapport à la copie que vous avez faite la dernière fois vous redémarrez.

        Comme je l'ai dit dans un commentaire, utilisez votre imagination.


4 commentaires

Apprécier l'aperçu. BTW - Ce n'est pas un scénario de synchronisation de fichier. Nous analysons les fichiers de configuration (qui sont grands), puis s'il y a une modification, une mise à jour de DB (qui prend du temps). C'est un programme hérité. Pas quelque chose où il est logique d'utiliser rsync.


Vous pouvez gérer cela avec rsync . Cela prend juste un peu d'imagination. Sinon, si ce n'est pas un problème de synchronisation du système de fichiers (distant), vous pouvez simplement comparer des fichiers dans un "ancien" et "nouveau" arbre de fichiers. Il y a aussi des utilitaires Linux / Unix pour le faire aussi.


Oui, et si vous allez avec la suggestion de @ Stephenc, et que vous utilisez au moins Java 12 (je sais, ce n'est pas assez courant pour le code de production), vous devriez consulter Files.Mismatch (chemin, chemin) introduit dans Java 12.


Salut @stharpenc et axel, je crois ce qui est suggéré W rsync nécessite que la structure du répertoire d'origine soit disponible et que nous n'avons pas accès à l'ancien système de fichiers, tout ce que nous stockons à partir de l'ancien système de fichiers. est une capture ou une somme de contrôle des fichiers qui comptent. La routine de synchronisation fonctionne une fois que les anciens fichiers de configuration ont été écrasés avec les nouveaux fichiers de configuration. Pour clarifier la synchronisation ne se situe pas entre deux systèmes de fichiers, mais un ensemble de fichiers de configuration et un moteur de matrice de réglages appuyé par des tables MySQL. Les types de réglage XML définissent et la DB stocke les données par profil.



0
votes

Voici une routine que je cherche à générer un hash à partir de tous les fichiers d'un répertoire.

DirectoryDigest dd = new DirectoryDigest();
dd.update(csConfigDirPath, ".xml");
String currentPeripheralHash = dd.digest();


0 commentaires