Brevet FR2953306A1 — publié le 20110603

La présente invention concerne la gestion de fichiers informatiques et plus particulièrement un procédé, un programme d'ordinateur et un dispositif pour la gestion automatique de versions de fichiers dans un environnement informatique local, en mode utilisateur, pour permettre la création automatique de copies de chaque fichier susceptible d'être modifié par l'utilisateur. En informatique, il existe un besoin général de conserver des versions antérieures des fichiers modifiés afin de retrouver le contenu de tels fichiers suite à une erreur de manipulation ou pour retrouver une version antérieure lorsque des modifications s'avérant non fondées ou erronées sont identifiées. Les développeurs de logiciels éprouvent, en particulier, un tel besoin. II existe ainsi des solutions, généralement appelées gestionnaires de versions, permettant de maintenir un historique de fichiers, notamment de fichiers de type code source et documentation liés à un projet. Toutes les versions de chaque fichier sont enregistrées pour permettre de revenir en arrière en cas d'erreur, identifier des modifications introduites entre deux versions et gérer des branches parallèles de développement. Ces solutions sont en outre adaptées au travail collaboratif lorsque plusieurs personnes travaillent sur un même projet. II existe essentiellement deux approches de gestionnaires de versions : les modèles centralisés, par exemple CVS (sigle de Concurrent Versions System en terminologie anglo-saxonne), et les modèles distribués, par exemple Git. Comme son nom l'indique, le modèle centralisé utilise un serveur dans lequel sont mémorisés les fichiers, ces derniers étant copiés localement pour être modifiés par chaque utilisateur. Les modifications sont transmises au serveur qui peut alors gérer les différentes versions des fichiers. Selon le modèle distribué, chaque utilisateur possède son propre espace de stockage contenant l'ensemble des versions des fichiers. Un mécanisme de clonage et de synchronisation permet de gérer plusieurs utilisateurs. De tels modèles offrent généralement plus de flexibilité que les modèles centralisés. Ces solutions reposent sur la définition d'un système de fichiers (aussi appelé file-system en terminologie anglo-saxonne) spécifique ayant pour objet de gérer les fichiers ouverts en écriture afin d'en sauvegarder le contenu lors d'opération d'écriture. Cependant, la mise en oeuvre de ces solutions est souvent complexe et requiert généralement des droits particuliers, par exemple des droits d'administrateur. En effet, il est souvent nécessaire de recompiler le noyau du système d'exploitation utilisé, par exemple le noyau Linux (Linux est une marque), afin d'intégrer un système de fichiers spécifique. Le développement, l'installation et la maintenance de ces solutions représentent donc des frais non négligeables. En outre, toute erreur peut se traduite ici par la perte de données importantes. Par ailleurs, l'utilisation d'un système de fichiers spécifique peut limiter le champ d'application de telles solutions, notamment à travers un 20 réseau de communication. L'invention permet de résoudre au moins un des problèmes exposés précédemment. L'invention a ainsi pour objet un procédé pour ordinateur de gestion automatique de versions de fichiers dans un environnement informatique local 25 comprenant au moins une bibliothèque standard chargée dynamiquement, ladite bibliothèque standard comprenant au moins une fonction pour accéder à au moins un fichier, ce procédé comprenant les étapes suivantes, - interception d'un appel à ladite au moins une fonction ; création d'une copie dudit au moins un fichier faisant l'objet dudit 30 appel à ladite au moins une fonction ; et, - transmission dudit appel à ladite bibliothèque standard. Le procédé selon l'invention permet ainsi de créer simplement des copies des fichiers susceptibles d'être modifiés, de façon transparente pour l'utilisateur, sans modifier le noyau du système d'exploitation. En outre, les fichiers n'étant pas traités avant d'être copiés, ils ne peuvent être modifiés, ce qui représente un gage de sûreté fort. De plus, les commandes systèmes standard telles que les commandes cp, rm et mv ainsi que les commandes de type shell (langage permettant d'accéder au système d'exploitation) appelées par l'utilisateur bénéficient également de ces avantages. Par ailleurs, le procédé n'étant pas basé sur un système de fichiers, il est, par nature, compatible avec les systèmes de fichiers sous jacents, notamment les systèmes de fichiers physiques tels que les systèmes de fichiers étendus ext2 et ext3 et les systèmes de fichiers réseaux tels que NFS (sigle de Network File System en terminologie anglo-saxonne) et LUSTRE (LUSTRE est une marque). Selon un mode de réalisation particulier, le procédé comprend en outre une étape d'analyse d'au moins un paramètre dudit au moins un fichier, ladite étape de création d'une copie dudit au moins un fichier étant effectuée en réponse à ladite étape d'analyse. Le procédé selon l'invention permet ainsi de copier sélectivement les fichiers susceptibles d'être modifiés selon des caractéristiques propres à ces derniers. Une telle étape d'analyse comprend, par exemple, une étape d'analyse de la taille dudit au moins un fichier, une étape d'analyse du répertoire auquel appartient ledit au moins un fichier ou une étape d'analyse du type dudit au moins un fichier. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de compression de ladite copie dudit au moins un fichier afin de limiter, de façon simple, la place occupée par les copies dans les dispositifs de stockage utilisés. De façon avantageuse, le procédé comprend en outre une étape de comparaison du nombre de copies préalablement réalisées dudit au moins un fichier avec un seuil prédéterminé et, si ledit nombre de copies est supérieur audit seuil, de suppression d'au moins une desdites copies et de renommage d'au moins une desdites copies, distincte de ladite au moins une copie supprimée, préalablement à ladite étape de création de ladite copie. Le procédé selon l'invention permet ainsi de contrôler le nombre de copies liées à un fichier afin de limiter la place occupée par celles-ci dans les dispositifs de stockage utilisés. Lesdites étapes du procédé sont, de préférence, mises en oeuvre dans une bibliothèque chargée dynamiquement préalablement à l'exécution d'une application ou commande à l'origine dudit appel, le procédé pouvant en outre comprendre une étape d'installation de ladite bibliothèque, ladite étape d'installation étant réalisée dans un mode utilisateur. La génération, l'installation et la configuration d'une telle bibliothèque peuvent ainsi être réalisées en mode utilisateur, puisqu'elles interviennent entre une application ou commande et la bibliothèque standard, ce qui simplifie notamment singulièrement son développement et sa mise au point. Toujours selon un mode de réalisation particulier, le procédé comprend en outre une étape de configuration comprenant la définition d'une variable d'environnement de ladite bibliothèque. La configuration du procédé est ainsi particulièrement souple car elle peut être réalisée par l'utilisateur à l'aide de variables d'environnements qui permettent de spécifier le comportement de la bibliothèque. L'utilisateur peut ainsi définir des paramètres tels que le nombre de copies à conserver par fichier et les types de fichiers devant être copiés. L'invention a également pour objet un programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur ainsi qu'un dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé décrit précédemment. Les avantages procurés par ce programme d'ordinateur et ce dispositif sont similaires à ceux évoqués précédemment. D'autres avantages, buts et caractéristiques de la présente invention ressortent de la description détaillée qui suit, faite à titre d'exemple non limitatif, au regard des dessins annexés dans lesquels : - la figure 1 illustre schématiquement un exemple de structure logicielle permettant l'exécution d'une application ou d'une commande dans un environnement tel que Linux selon laquelle une copie des fichiers appelés et susceptibles d'être modifiés est automatiquement générée ; - la figure 2 illustre schématiquement un exemple d'algorithme pour créer des copies de fichiers lorsque ces derniers sont susceptibles d'être modifiés ; et, - la figure 3 illustre un exemple de dispositif adapté à mettre en oeuvre l'invention ou une partie de l'invention. De façon générale, l'invention a pour objet d'intercepter les appels aux bibliothèques standard utilisées pour la gestion de fichiers afin de créer automatiquement des versions de sauvegarde de ces derniers, sans intervention de l'utilisateur. Une telle solution est avantageusement basée sur l'utilisation d'une bibliothèque s'interposant entre les applications et la bibliothèque standard. Ainsi, il n'est pas nécessaire de recompiler le noyau du système d'exploitation ni de disposer de droits particuliers tels que des droits d'administrateur. A titre d'illustration, lorsque l'invention est mise en oeuvre dans un environnement tel que Linux, les appels à la bibliothèque libc susceptibles de modifier un fichier sont interceptés pour créer une copie de ce fichier avant d'exécuter la fonction appelée. La bibliothèque libc est une bibliothèque C qui gère les appels système et les fonctions de base telles que open, read, write et close. Cette bibliothèque est utilisée par tous les programmes liés dynamiquement. II est rappelé ici qu'une bibliothèque peut être considérée comme un fichier archives comprenant des fichiers exécutables permettant d'exécuter des fonctions appelées par une application. A ces fins, l'application est liée à la bibliothèque lors de la compilation, de façon statique ou dynamique. Pour permettre d'intercepter les appels à une bibliothèque, le lien doit être dynamique, c'est-à-dire que la bibliothèque doit être appelée lors de l'exécution de l'application (dans le cas d'un lien statique, la bibliothèque est intégrée à l'application). La figure 1 illustre schématiquement un exemple d'une structure logicielle permettant l'exécution d'une application ou d'une commande dans un environnement tel que Linux selon laquelle une copie des fichiers appelés et susceptibles d'être modifiés est automatiquement générée. La structure logicielle illustrée et référencée 100 comprend ici un noyau Linux 105 auquel sont associées des bibliothèques et en particulier la bibliothèque standard libc 110 ainsi que la bibliothèque 115, appelée bibliothèque BVFS (sigle de Bull Versioning File Solution en terminologie anglo-saxonne, Bull est une marque), permettant d'intercepter des appels à la bibliothèque standard libc 110 et de créer des copies de fichiers. La structure 100 comprend en outre des applications 120 et/ou un éditeur de commandes 125 standard, non spécifiquement développés pour mettre en oeuvre l'invention. Ainsi, les applications 120 ainsi que l'éditeur de commande 125 font appel à la bibliothèque standard libc 110 mais non à la bibliothèque BVFS 115. Cependant, selon un mode de réalisation particulier, la bibliothèque BVFS 115 est chargée dynamiquement, par exemple à l'aide de la variable d'environnement LD_PRELOAD, avant l'exécution d'applications faisant appel à des fonctions exécutées par la bibliothèque standard. II est rappelé ici que la variable d'environnement LD_PRELOAD permet de forcer le chargement d'une bibliothèque additionnelle lors de l'exécution d'une application logicielle. Ainsi, lorsque les applications 120 et l'éditeur de commandes 125 font appel à la bibliothèque standard libc 110, la bibliothèque BVFS 115 est chargée et les appels à la bibliothèque standard libc 110 sont interceptés pour exécuter des fonctions de la bibliothèque BVFS 115 avant l'exécution des fonctions appelées de la bibliothèque standard libc 110. La figure 2 illustre schématiquement un exemple d'algorithme 200 pour créer des copies de fichiers lorsque ces derniers sont susceptibles d'être modifiés, c'est-à-dire un exemple d'algorithme pouvant être implémenté dans la bibliothèque BVFS 115. Comme illustré, une première étape (étape 205) consiste à détecter les appels à certaines fonctions prédéfinies de la bibliothèque standard libc. Ces fonctions sont, de préférence, toutes les fonctions susceptibles de modifier un fichier, c'est-à-dire, notamment, les fonctions d'ouverture de fichiers en mode écriture, les fonctions d'effacement de fichiers et les fonctions de renommage de fichiers. Si un tel appel est détecté, une étape suivante (étape 210), optionnelle, vise l'analyse de certains paramètres du ou des fichiers faisant l'objet de la fonction dont l'appel est détecté afin de déterminer si une copie de ceux-ci doit être réalisée. Par exemple, il peut être décidé que des fichiers de certains types, de certaines tailles ou appartenant à certains emplacements particuliers ne sont pas copiés lorsqu'ils font l'objet d'une fonction appelée. A titre d'illustration, les fichiers de type image, les fichiers dont la taille est supérieure à 1 Mo et les fichiers situés dans un répertoire temporaire peuvent ne pas être copiés. A ces fins, des paramètres prédéterminés sont comparés avec les 15 paramètres des fichiers visés dont les caractéristiques sont accessibles selon des commandes standard. Un test est alors effectué (étape 215) pour déterminer si le ou les fichiers doivent être copiés. Dans l'affirmative, ces fichiers sont copiés (étape 220) selon des 20 règles prédéterminées définissant notamment le mode de copie, par exemple avec ou sans compression, l'indication du ou des répertoires où doivent être placées les copies, par exemple un répertoire prédéterminé ou le répertoire contenant le fichier d'origine, ainsi que les règles de nommage des copies. Lorsque le ou les fichiers ont été copiés ou lorsqu'il n'est pas 25 nécessaire de les copier (étape 215), la fonction interceptée est appelée (étape 225). Ainsi, selon l'invention, une bibliothèque BVFS est définie pour s'interposer entre les applications liées dynamiquement et la bibliothèque standard libc. La bibliothèque BVFS intercepte tous les appels aux fonctions de 30 la bibliothèque libc susceptibles de modifier un fichier, aussi bien son nom que son contenu. Ces fonctions sont notamment les fonctions d'ouverture en écriture d'un fichier, d'effacement d'un fichier et de renommage d'un fichier. Lorsqu'une de ces fonctions de la bibliothèque standard libc est appelée, c'est en fait la bibliothèque BVFS qui est appelée et qui se charge de créer, de façon transparente pour l'utilisateur, une copie de sauvegarde du fichier concerné. Ensuite, la fonction demandée de la bibliothèque standard libc est effectivement appelée par la bibliothèque interposée BVFS et l'application travaille normalement sur le fichier. Comme indiqué précédemment, les fichiers originaux des utilisateurs ne sont pas modifiés par la bibliothèque BVFS. II est rappelé ici que la génération, l'installation et la configuration de la bibliothèque BVFS, intervenant entre des applications et la bibliothèque standard libc, peuvent être réalisées en mode utilisateur car elles ne requièrent aucun droit particulier, notamment aucun droit d'administration. La configuration est avantageusement réalisée au niveau de l'utilisateur par des variables d'environnements. Comme indiqué précédemment, les commandes systèmes standard telles que cp, rm et mv ainsi que les commandes de type shell (langage permettant d'accéder au système d'exploitation) appelées par l'utilisateur bénéficient également des avantages procurés par la bibliothèque BVFS qui, en outre, est, par nature compatible avec tous les systèmes de fichiers sous jacents, aussi bien physiques tels que ext2 et ext3 que réseau tels que NFS et LUSTRE. De façon avantageuse, les copies sont des fichiers cachés, c'est-à-dire commençant par « . » sous Linux, dont les noms reprennent le nom des fichiers d'origine avec un indice incrémenté à chaque copie. Un caractère particulier, par exemple « : », est, de préférence, placé entre le nom du fichier d'origine et l'indice. A titre d'illustration, en considérant un fichier appelé readme.txt, le fichier .readme.txt:000 est créé lors de la première modification du fichier readme.txt. A ces fins, comme indiqué précédemment, le fichier readme.txt est copié avant qu'il ne puisse être modifié. Ensuite, lors de la seconde modification, le fichier .readme.txt :001 est créé et ainsi de suite. Toujours de façon avantageuse, le nombre maximal de copies d'un fichier est limité, il peut être, par exemple, égal à 32. Lorsque ce nombre est atteint, les révisions les plus anciennes sont effacées et les plus récentes renommées en conséquence. A titre d'exemple, si le nombre maximum de copies est 4, les fichiers suivants seront créés et mis à jour après au moins 4 accès au fichier correspondant susceptibles de le modifier : . readme. txt. 000 . readme. txt. 001 . readme. txt. 002 , readme. txt: 003 où le fichier .readme.txt.003 représente la version la plus récente du fichier readme.txt. II est observé ici que le fichier original readme.txt n'est jamais modifié par la bibliothèque BVFS (il n'est, de préférence, jamais ouvert en écriture afin 15 d'en garantir l'intégrité). Les paramètres utilisés par la bibliothèque BVFS sont, de préférence, mémorisés dans des variables d'environnement telles que BVFS_DEBUG, BVFS_OPTIONS, BVFS_EXCLUDE_DIR, BVFS_EXCLUDE_FILES, BVFS_COMPRESS_FILES et BVFS_SIZE. Ils 20 peuvent être modifiés par l'utilisateur selon ses besoins. La variable d'environnement BVFS_DEBUG contient par exemple un nombre entier définissant le type de suivi d'exécution de la bibliothèque BVFS durant son exécution. A titre d'illustration, ce nombre entier peut prendre les valeurs suivantes : 25 1 pour activer l'affichage de l'analyse des options contenues dans la variable d'environnement BVFS_OPTIONS ; 2 pour suivre l'exécution de fonctions visant des fichiers non copiés par la bibliothèque BVFS et les raisons pour lesquelles ces fichiers n'ont pas été copiés ; 30 4 pour suivre l'exécution des fonctions de la bibliothèque standard libc interceptées par la bibliothèque BVFS et afficher leurs paramètres ; 8 pour suivre l'exécution des fonctions de copie de fichiers de la bibliothèque BVFS ; 16 pour suivre l'exécution d'appels à certaines fonctions prédéfinies, par exemple des fonctions de compression (bzip2), copie (cp), comparaison (cmp) et de suppression (rm), internes ou externes ; et, 32 pour suivre le fonctionnement du système de reconnaissance de motifs pour les fichiers, les répertoires à exclure et les fichiers à compresser. Naturellement ces paramètres peuvent être cumulés. Ainsi, la valeur 10 permet de suivre l'exécution de fonctions visant des fichiers non copiés par la bibliothèque BVFS et les raisons pour lesquelles ces fichiers n'ont pas été copiés (valeur 2) ainsi que l'exécution des fonctions de copie de fichiers de la bibliothèque BVFS (valeur 8). Pour améliorer la visibilité et l'interprétation des informations affichées, les différents types d'information sont, de préférence, affichés dans des couleurs différentes. La variable d'environnement BVFS_OPTIONS permet ici de changer le fonctionnement global de la bibliothèque BVFS. Les options suivantes peuvent, par exemple, être utilisées : no rename : les fichiers renommés ne sont pas copiés ; trace only : permet de suivre l'exécution des fonctions appelées (de façon similaire à la valeur 4 de la variable d'environnement BVFS_DEBUG) sans que des copies soient réalisées ; no skip hidden : les fichiers cachés ou situés dans des répertoires cachés sont copiés ; nrev= : pour définir le nombre de copies d'un fichier ; no unlink : les fichiers effacés ne sont pas copiés ; et, log file= : fichier où sont mémoriser les informations d'exécution. A nouveau, il est possible de cumuler plusieurs ou tous ces 30 paramètres. La variable d'environnement BVFS EXCLUDE DIR est ici une liste de répertoires, de préférence séparés par des caractères prédéterminés, qui indique les répertoires dont les fichiers ne doivent pas être copiés. Par défaut, tous les répertoires temporaires sont, de préférence, exclus. Des caractères génériques peuvent être utilisés. De façon similaire, la variable BVFS_EXCLUDE_FILES contient ici une liste de noms de fichiers, de préférence séparés par des caractères prédéterminés, qui indique les fichiers ne devant pas être copiés. Des caractères génériques peuvent être utilisés. La variable BVFS COMPRESS FILES contient ici une liste de noms de fichiers, de préférence séparés par des caractères prédéterminés, qui indique les fichiers devant être compressés lorsqu'ils sont copiés. Des caractères génériques peuvent être utilisés. Enfin, la variable d'environnement BVFS_SIZE contient ici un nombre entier représentant la taille maximale des fichiers copiés. Seuls les fichiers dont la taille est plus petite que ce nombre entier, mais non nulle, sont copiés. De façon avantageuse, des fonctions annexes peuvent être utilisées pour manipuler les fichiers originaux et leurs copies. Ces fonctions sont, par exemple, accessibles via des commandes similaires à des commandes Linux. Ces fonctions permettent d'accéder aux fichiers originaux et à leurs copies, compressées ou non, pour les afficher, les comparer et restaurer des fichiers originaux selon une copie particulière. De telles fonctions sont, par exemple, les suivantes : showall pour recherche récursivement et afficher toutes les copies à partir du répertoire racine d'un utilisateur ; cleanall pour rechercher récursivement et effacer toutes les copies à partir du répertoire racine d'un utilisateur ; clean pour effacer toutes les copies du répertoire courant ; ls pour afficher un fichier d'origine et ses copies si un nom est donné en paramètre ou toutes les copies du répertoire courant ; Il pour afficher un fichier d'origine, ses copies et les détails des fichiers si un nom est donné en paramètre ou toutes les copies et leurs détails du répertoire courant ; cat pour afficher la copie du fichier (il s'agit d'une commande équivalente à la commande Linux cat . : ou bzcat . : si ce type de fichier est compressé) ; rm pour effacer toutes les copies du fichier , sans effacer, ici, le fichier lui-même ; diff pour afficher les différences entre le fichier et sa copie , compressée ou non ; file pour indiquer si la copie du fichier est compressée ou non ; rv pour comparer les copies et (compressées ou non) du fichier ; rt pour restaurer le fichier à partir de sa copie , compressée ou non. Si le fichier existe déjà, une copie supplémentaire est créée ; et, cr pour crée une copie du fichier . Un dispositif adapté à mettre en oeuvre l'invention ou une partie de l'invention, notamment l'algorithme décrit en référence à la figure 2, est illustré sur la figure 3. Le dispositif 300 est par exemple un ordinateur de type PC (sigle de Persona) Computer en terminologie anglo-saxonne). Le dispositif 300 comporte ici un bus de communication 302 auquel sont reliés : - une unité centrale de traitement ou microprocesseur 303 (ou CPU, sigle de Central Processing Unit en terminologie anglo-saxonne) ; une mémoire morte 304 (ROM, acronyme de Read Only Memory 25 en terminologie anglo-saxonne) pouvant comporter les programmes "Prog", "Prog1" et "Prog2" ; - une mémoire vive ou mémoire cache 306 (RAM, acronyme de Random Access Memory en terminologie anglo-saxonne) comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au 30 cours de l'exécution des programmes précités ; et, - une interface de communication 318 adaptée à transmettre et à recevoir des données. De préférence, le dispositif 300 dispose en outre : - d'un écran 308 permettant de visualiser des données et/ou de servir d'interface graphique avec l'utilisateur qui pourra interagir avec les programmes selon l'invention, à l'aide d'un clavier et d'une souris 310 ou d'un autre dispositif de pointage tel qu'un crayon optique, un écran tactile ou une télécommande ; - d'un disque dur 312 pouvant comporter les programmes "Prog", "Progl" et "Prog2" précités et des données traitées ou à traiter selon l'invention ; et, - d'un lecteur de cartes mémoires 314 adapté à recevoir une carte mémoire 316 et à y lire ou à y écrire des données traitées ou à traiter selon l'invention. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments inclus dans le dispositif 300 ou reliés à lui. La représentation du bus n'est pas limitative et, notamment, l'unité centrale est susceptible de communiquer des instructions à tout élément du dispositif 300 directement ou par l'intermédiaire d'un autre élément du dispositif 300. Le code exécutable de chaque programme permettant au dispositif programmable de mettre en oeuvre les processus selon l'invention, peut être stocké, par exemple, dans le disque dur 312 ou en mémoire morte 304. Selon une variante, la carte mémoire 316 peut contenir des données ainsi que le code exécutable des programmes précités qui, une fois lus par le dispositif 300, sera stocké dans le disque dur 312. Selon une autre variante, le code exécutable des programmes pourra être reçu, au moins partiellement, par l'intermédiaire de l'interface 318, pour être stocké de façon identique à celle décrite précédemment. De manière plus générale, le ou les programmes pourront être chargés dans un des moyens de stockage du dispositif 300 avant d'être 30 exécutés. L'unité centrale 303 va commander et diriger l'exécution des instructions ou portions de code logiciel du ou des programmes selon l'invention, instructions qui sont stockées dans le disque dur 312 ou dans la mémoire morte 304 ou bien dans les autres éléments de stockage précités. Lors de la mise sous tension, le ou les programmes qui sont stockés dans une mémoire non volatile, par exemple le disque dur 312 ou la mémoire morte 304, sont transférés dans la mémoire vive 306 qui contient alors le code exécutable du ou des programmes selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre de l'invention. Naturellement, pour satisfaire des besoins spécifiques, une personne 10 compétente dans le domaine de l'invention pourra appliquer des modifications dans la description précédente. REVENDICATIONS1. Procédé pour ordinateur de gestion automatique de versions de fichiers dans un environnement informatique local comprenant au moins une bibliothèque standard chargée dynamiquement, ladite bibliothèque standard comprenant au moins une fonction pour accéder à au moins un fichier, ce procédé étant caractérisé en ce qu'il comprend les étapes suivantes, - interception (205) d'un appel à ladite au moins une fonction ; - création (220) d'une copie dudit au moins un fichier faisant l'objet dudit appel à ladite au moins une fonction ; et, - transmission (225) dudit appel à ladite bibliothèque standard. 2. Procédé selon la revendication 1 comprenant en outre une étape d'analyse (210) d'au moins un paramètre dudit au moins un fichier, ladite étape de création d'une copie dudit au moins un fichier étant effectuée en réponse à ladite étape d'analyse. 3. Procédé selon la revendication précédente selon lequel ladite étape d'analyse comprend une étape d'analyse de la taille dudit au moins un fichier, une étape d'analyse du répertoire auquel appartient ledit au moins un fichier ou une étape d'analyse du type dudit au moins un fichier. 4. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de compression de ladite copie dudit au moins un fichier. 5. Procédé selon l'une quelconque des revendications précédentes comprenant en outre une étape de comparaison du nombre de copies préalablement réalisées dudit au moins un fichier avec un seuil prédéterminé et, si ledit nombre de copies est supérieur audit seuil, de suppression d'au moins une desdites copies et de renommage d'au moins une desdites copies, distincte de ladite au moins une copie supprimée, préalablement à ladite étape de création de ladite copie. 6. Procédé selon l'une quelconque des revendications précédentes selon lequel lesdites étapes sont mises en oeuvre dans une bibliothèque chargée dynamiquement préalablement à l'exécution d'une application ou commande à l'origine dudit appel. 7. Procédé selon la revendication précédente comprenant en outre une étape d'installation de ladite bibliothèque, ladite étape d'installation étant réalisée dans un mode utilisateur. 8. Procédé selon la revendication précédente comprenant en outre une étape de configuration, ladite étape de configuration comprenant la définition d'une variable d'environnement de ladite bibliothèque. 9. Programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 5 lorsque ledit programme est exécuté sur un ordinateur. 10. Dispositif comprenant des moyens adaptés à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8.