Le traitement

accédant au fichier quand le scan de virus a eu lieu. C’est un renseignement important pour le dépannage, particulièrement quand un scan n’est pas parvenu à réparer un fichier infecté. A moins que vous n’ayez spécifié l’option runtime *NOFAILCLO, le programme appelant a été terminé. Connaître l’utilisateur qui a le dernier abouti à un scan peut vous aider à traquer et résoudre les défaillances applicatives de nature virale.

L’autre renseignement intéressant est l’état du scan. « Successful » indique que le fichier a été scanné et, s’il était infecté, bien réparé. Les attributs de fichier n’indiquent pas quand un fichier a été scanné et trouvé propre, mais le journal d’application du scanner devrait fournir ce renseignement, à la condition bien sûr que l’auteur du scanner ait bien voulu journaliser les événements de scan individuels. Quand un scan est réussi, les valeurs scan signature, binary flag et CCSID du fichier sont remplies dans la boîte de dialogue Properties. Si la rubrique scan signature indique « Does not match », comme dans la figure 4, c’est que le fichier a été scanné par le passé avant que l’ensemble de définitions de virus actuel ne soit en vigueur. De tels fichiers seront automatiquement rescannés dès leur prochaine réouverture. Le binary flag indique que le fichier a été traité comme un stream binaire (et donc scanné pour trouver les signatures de virus du code objet, plutôt que les signatures texte seulement). Les valeurs CCSID indiquent quels ensembles de code ont été utilisés lors du scanning du fichier. Ici, 500 (EBCDIC) et 1200 (UCS-2 ASCII).

Si le programme de scanning échoue à cause d’une erreur interne ou d’une erreur de coding, l’état est « Unsuccessful ». L’autre information sur le résultat du scan est vide dans ce cas, puisque le scan a échoué en raison d’un bogue dans le scanner. Si le programme de scanning échoue parce qu’un fichier infecté n’a pu être réparé, l’état est également « Unsuccessful », mais la signature du scan et les autres résultats sont renseignés. Une réparation ne peut échouer que pour deux raisons : si *NOWRTUPG a été spécifié, ou si le programme de scanning a renvoyé un résultat d’échec explicite.

Il faut bien voir que le comportement du scanner dépend beaucoup de son développeur. Les connexions de validation de scan d’IBM offrent une grande liberté de choix quant aux définitions de virus, aux méthodes de scanning et aux techniques de réparation. Par exemple, un développeur pourrait choisir de ne pas mettre en oeuvre le scanning pour le EBCDIC CCSID (500) ou de supprimer les fichiers infectés qui ne peuvent pas être réparés.

Un développeur pourrait faire une copie de sauvegarde d’un fichier avant de le réparer ou, tout simplement, copier les fichiers infectés dans une zone de conservation (quarantaine) au lieu de les réparer. Tout est laissé à l’initiative du fournisseur, en laissant beaucoup de place pour l’ingéniosité et les fonctions.