

2023-11-05 22:15 BugFix & Mise à jour: jSAVF 1.80 Un utilisateur souhaitait ouvrir un volumineux fichier image d'une bande magnetique contenant plusieurs sauvegardes avec jSAVF, donc j'ai effectué quelques changements pour le permettre. Ca m'a aussi permis d'ajouter un support limité des fichiers images de disques optiques (ISO9660 uniquement pour l'instant, pas d'UDF) vu que ceux-ci peuvent aussi contenir plusieurs sauvegardes. L'outil d'acquisition de bande magnétique qu'il a utilisé produit un fichier au format AWSTAPE (cf. Description, Emulateur Hercules-390), qui insère une entête de 6 octets avant chaque block de la bande magnétique. Ce format n'est pas idéal vu qu'il décrit la taille du segment précédent et suivant sur des mots de 16bit, alors que les bandes magnétiques modernes semblent avoir des blocks de 256KO ou plus. Ceci produit des débordements, donc par exemple un block dont la taille est décrite par 0xF000 dans l'entête de block peut vouloir dire soit 0x0F000, 0x1F000, 0x2F000 ou 0x3F000 pour une bande avec des blocs de taille 0x40000 (256KO) décrits dans le libellé de bande ANSI X3.27-1978 correspondant au fichier. jSAVF contourne le problème en cherchant aux différents déplacements une entête de block AWSTAPE valide et décrivant une taille de block précédent égale à celle du block courrant modulo 65536. En cas de malchance il peut arriver que de la donnée du block à un de ces déplacements ressemble à l'entête recherchée, donc dans le cas ou jSAVF trouve plus d'une entête suivante possible la lecture s'interrompra avec une erreur. Si vous vous retrouvez dans ce cas je pourrais peut-être améliorer cette recherche en considérant le block suivant, mais vu que pour le moment ceci semble suffisant je n'ajouterais pas de complexité en plus sauf si quelqu'un n'arrive pas a ouvrir une bande magnétique sans. Vu que parcourir l'ensemble des entêtes alternatives d'une bande de plusieurs giga-octets pour trouver toutes les sauvegardes présentes dedans peut prendre un temps certain, jSAVF va générer un fichier d'index nommé "xxx.jsavf_awstape_index.bin" à côté d'un fichier image de bande magnétique nommé "xxx" si ce parcours prend plus de 3s. L'index contient les libellés de bande pour chaque fichier, ainsi que des tables décrivant la position des entêtes de block afin de pouvoir rapidement convertir une position dans une des sauvegardes en une position dans le fichier image de bande magnétique. Ceci permet a jSAVF d'ouvrir le fichier quasi instantanément la prochaine fois, et ne nécessite que peu de place (~1MO d'index pour une bande de ~30GO). Lorsqu'il y a plusieurs sauvegardes dans un fichier, jSAVF va maintenant demander à l'utilisateur d'en sélectionner un à ouvrir. Pour les scripts batch ceci est géré en utilisant une nouvelle API jsavf:openMultiSaveFile(path, selector) qui applèle une fonction selector fournie par l'utilisateur avec la liste des sauvegardes trouvées dans la bande magnétique ou le disque optique, et s'attend en retour a recevoir le fichier à ouvrir. Ceci permet à un script de sélectionner une sauvegarde par sa taille, son nom ou son numéro d'ordre. La dépendence JEXL a été mise à jour en v3.3 pour rendre ceci possible, donc si vous rencontrez des incompatibilités dans vos scripts merci de m'en informer pour que je vois si c'est quelque chose que je peux corriger. J'ai ajouté quelques classes à l'API batch pour permettre de convertir du texte en int ou long, et décrit ceci dans la documentation de l'API. Cette version corrige aussi deux bugs: Certaines extractions n'arrivaient pas à déterminer la structure d'un élément sauvegardé à cause d'une erreur dans la manière dont jSAVF calculait la position de la première section lorsque l'entête faisait exactement 4096 octets. Certaines extractions CSV avec des champs CHAR VARYING, CLOB ou BLOB ne pouvaient pas être réalisées lorsque la quantité totale de données dans ces champs dépassait une certaine taille, ce qui se produit avec des tables ayant beaucoup d'enregistrements ou avec assez de donnée dedans. jSAVF arrive maintenant a extraire ce type de tables mais peut encore avoir des difficultés si la longueur des valeurs dans les champs CLOB ou BLOB est très grande. N'hésitez pas à me contacter si vous êtes confrontés à un problème de ce type. L'extraction CSV des champs de type BLOB a été modifiée pour extraire leurs valeurs sous forme de chaine hexadécimale, en effet écrire du binaire brut dans un CSV encodé en UTF-8 n'était pas très exploitable. J'ai aussi mis à jour les dépendences de jSAVF ainsi que la version du JRE embarqué pour la version installable pour Windows. jSAVF nécessite donc maintenant une version Java 21 ou plus récente. Si vous avez des problèmes avec cette version de jSAVF, n'hésitez pas a m'en informer.

2023-11-05 22:15

BugFix & Mise à jour: jSAVF 1.80

Un utilisateur souhaitait ouvrir un volumineux fichier image d'une bande magnetique contenant plusieurs sauvegardes avec jSAVF, donc j'ai effectué quelques changements pour le permettre. Ca m'a aussi permis d'ajouter un support limité des fichiers images de disques optiques (ISO9660 uniquement pour l'instant, pas d'UDF) vu que ceux-ci peuvent aussi contenir plusieurs sauvegardes.

L'outil d'acquisition de bande magnétique qu'il a utilisé produit un fichier au format AWSTAPE (cf. Description, Emulateur Hercules-390), qui insère une entête de 6 octets avant chaque block de la bande magnétique.

Ce format n'est pas idéal vu qu'il décrit la taille du segment précédent et suivant sur des mots de 16bit, alors que les bandes magnétiques modernes semblent avoir des blocks de 256KO ou plus. Ceci produit des débordements, donc par exemple un block dont la taille est décrite par 0xF000 dans l'entête de block peut vouloir dire soit 0x0F000, 0x1F000, 0x2F000 ou 0x3F000 pour une bande avec des blocs de taille 0x40000 (256KO) décrits dans le libellé de bande ANSI X3.27-1978 correspondant au fichier.

jSAVF contourne le problème en cherchant aux différents déplacements une entête de block AWSTAPE valide et décrivant une taille de block précédent égale à celle du block courrant modulo 65536. En cas de malchance il peut arriver que de la donnée du block à un de ces déplacements ressemble à l'entête recherchée, donc dans le cas ou jSAVF trouve plus d'une entête suivante possible la lecture s'interrompra avec une erreur. Si vous vous retrouvez dans ce cas je pourrais peut-être améliorer cette recherche en considérant le block suivant, mais vu que pour le moment ceci semble suffisant je n'ajouterais pas de complexité en plus sauf si quelqu'un n'arrive pas a ouvrir une bande magnétique sans.

Vu que parcourir l'ensemble des entêtes alternatives d'une bande de plusieurs giga-octets pour trouver toutes les sauvegardes présentes dedans peut prendre un temps certain, jSAVF va générer un fichier d'index nommé "xxx.jsavf_awstape_index.bin" à côté d'un fichier image de bande magnétique nommé "xxx" si ce parcours prend plus de 3s. L'index contient les libellés de bande pour chaque fichier, ainsi que des tables décrivant la position des entêtes de block afin de pouvoir rapidement convertir une position dans une des sauvegardes en une position dans le fichier image de bande magnétique. Ceci permet a jSAVF d'ouvrir le fichier quasi instantanément la prochaine fois, et ne nécessite que peu de place (~1MO d'index pour une bande de ~30GO).

Lorsqu'il y a plusieurs sauvegardes dans un fichier, jSAVF va maintenant demander à l'utilisateur d'en sélectionner un à ouvrir. Pour les scripts batch ceci est géré en utilisant une nouvelle API jsavf:openMultiSaveFile(path, selector) qui applèle une fonction selector fournie par l'utilisateur avec la liste des sauvegardes trouvées dans la bande magnétique ou le disque optique, et s'attend en retour a recevoir le fichier à ouvrir. Ceci permet à un script de sélectionner une sauvegarde par sa taille, son nom ou son numéro d'ordre. La dépendence JEXL a été mise à jour en v3.3 pour rendre ceci possible, donc si vous rencontrez des incompatibilités dans vos scripts merci de m'en informer pour que je vois si c'est quelque chose que je peux corriger. J'ai ajouté quelques classes à l'API batch pour permettre de convertir du texte en int ou long, et décrit ceci dans la documentation de l'API.

Cette version corrige aussi deux bugs:

Certaines extractions n'arrivaient pas à déterminer la structure d'un élément sauvegardé à cause d'une erreur dans la manière dont jSAVF calculait la position de la première section lorsque l'entête faisait exactement 4096 octets.
Certaines extractions CSV avec des champs CHAR VARYING, CLOB ou BLOB ne pouvaient pas être réalisées lorsque la quantité totale de données dans ces champs dépassait une certaine taille, ce qui se produit avec des tables ayant beaucoup d'enregistrements ou avec assez de donnée dedans. jSAVF arrive maintenant a extraire ce type de tables mais peut encore avoir des difficultés si la longueur des valeurs dans les champs CLOB ou BLOB est très grande. N'hésitez pas à me contacter si vous êtes confrontés à un problème de ce type.

L'extraction CSV des champs de type BLOB a été modifiée pour extraire leurs valeurs sous forme de chaine hexadécimale, en effet écrire du binaire brut dans un CSV encodé en UTF-8 n'était pas très exploitable.

J'ai aussi mis à jour les dépendences de jSAVF ainsi que la version du JRE embarqué pour la version installable pour Windows. jSAVF nécessite donc maintenant une version Java 21 ou plus récente.

Si vous avez des problèmes avec cette version de jSAVF, n'hésitez pas a m'en informer.