Détermination de la plage d'octets de début et de fin modifiés dans un fichier

Question

Je travaille sur un petit utilitaire expérimental à utiliser au sein de notre société qui indexe les notes stockées dans notre logiciel CRM personnalisé pour la recherche en texte intégral. Ces notes sont stockées dans une base de données Btrieve (un fichier appelé NOTES.DAT). Il est possible de se connecter à la base de données et d'extraire les notes pour l'indexation à l'aide du fournisseur ADO.NET de Pervasive. Cependant, l'indexeur parcourt actuellement chaque note et la réindexe toutes les 5 minutes. Cela semble totalement inefficace.

Malheureusement, notre logiciel de gestion de la relation client n'a aucun moyen de signaler au service d'indexation qu'une note a été modifiée, car il est possible que la base de données existe sur une machine distante (et que les développeurs n'écriront pas de procédure. communiquer avec mon service via un réseau, car il ne s’agit que d’un projet de loisir pour le moment).

Plutôt que d’abandonner, j’aimerais saisir cette occasion pour en apprendre un peu plus sur les bases de données brutes Btrieve. Alors, voici mon plan ...

Le fichier NOTES.DAT doit être partagé, car notre logiciel CRM utilise l’API Btrieve plutôt que le pilote ODBC (ce qui signifie que les installations client doivent pouvoir voir le fichier lui-même sur le réseau). Je voudrais surveiller ce fichier (en utilisant quelque chose comme FileSystemWatcher?) Et ensuite déterminer les octets qui ont été modifiés. En utilisant cette information, je vais essayer de calculer le record à cette position et d’obtenir sa clé primaire. Ensuite, l'indexeur mettra à jour uniquement cet enregistrement à l'aide du fournisseur ADO.NET de Pervasive.

Le problème (à part le fait que je ne connais pas encore la structure des fichiers Btrieve ou si la détermination de la clé primaire à partir des données brutes est possible) est que je ne sais pas comment déterminer les plages de début et de fin. d'octets modifiés dans NOTES.DAT.

Je pourrais comparer deux versions, mais cela impliquerait de stocker une copie de NOTES.DAT quelque part (et cela peut être assez volumineux, d’où la raison d’un service d’indexation de texte intégral).

Quel est le moyen le plus efficace de le faire?

Merci!

EDIT: il est possible d’ajouter, éditer ou supprimer plusieurs notes dans une transaction. Par conséquent, si possible, la méthode doit pouvoir déterminer plusieurs plages d’octets distinctes.

Answer 1

Si votre fichier NOTES.DAT est stocké sur une partition NTFS , vous devriez alors pouvoir effectuer l’une des opérations suivantes:

• utilisez le journal USN pour identifier modifie votre fichier (préféré)
• utilisez le service de copie fantôme de volume pour suivre les modifications apportées à votre fichier en effectuant des instantanés périodiques VSS (très rapide), puis soit:
  • diff versions N et N-1 (probablement pas aussi lent que la réindexation, mais toujours lent), ou
  • approfondir et essayer de faire diff le $ Mft pour déterminer quels blocs ont été modifiés pour quels décalages pour le (s) fichier (s) d'intérêt (beaucoup plus complexe, mais aussi beaucoup plus rapide - mais pas aussi rapide, fiable et simple que d'utiliser le journal USN)

L’utilisation du journal USN devrait être votre méthode préférée. Vous pouvez utiliser l'utilitaire FSUTIL pour créer et tronquer le journal USN.