Structure d'archive, altération des données fichiers

[graph100]

Lors de la création d'un format de fichier conçu pour le stockage d'une architecture complète de dossier et de fichier,
est-il indispensable de prévoir des sécurités contre la perte de donnée due à des copies malencontreuses.

Comme sécurité j'entends un système qui préviens l'utilisateur que des fichiers de l'archive sont inaccessibles, et un système
qui permet de récupérer les fichiers accessibles et reconstruire l'architecture originale.

Quelles sont les causes possibles d'altération d'un fichier dans le cas à part la copie.
Peut-on altérer un fichier en l'ouvrant en lecture ? Y-a t'il des risques lors de la troncature du fichier d'endommager les données
se situant au dessus ?

Autant de questions auxquelles je n'ai pas la réponse :s, aussi je me tourne vers vous, le regard plein d'espoir

Actuellement j'utilise une structure des données telle que suit :

en-tête :

[QUAD : adresse du bloc de fin] [LONG : nb de fichier]

Corps :

[LONG : taille fichier] [DATA : contenu du fichier]
. . . . . .

Bloc de FIN

{si dossier} : [QUAD : =0] [LONG : nb de fichier dans le dossier] [STRING : nom du dossier (sans le chemin, et sans les /)]
{si fichier} : [QUAD : adresse des données du fichier] [STRING : nom du fichier]
. . . . . .

J'ai besoin de rajouter la possibilité de stocker des commentaires de tailles variables dans ce fichier, et j'aimerai faire ça en utilisant la troncature de fichier,

Et je me demande si il n'y a pas un risque de rendre tout le fichier illisible en cas d'altération.
En effet, en l'état, si l'adresse du bloc de fin change, il n'est plus possible de retrouver les différents fichiers et leurs noms, ni de recréer l'architecture initiale.

Cependant, si il n'est pas possible que l'adresse du bloc de fin change, même en cas d'altération, ca ne vaut pas la peine que je change cette structure des données.

Quel est votre avis sur la question

[Patrick88]

lors d'un crash du programme utilisant le/les fichier/s, ceux ci peuvent se trouver être altérés. je pense principalement à cette d...e d'AutoCAD qui après un crash, propose la récupération des fichiers. il y a presque toujours des donnée incomplète / tronquée qui apparaissent avec le temps. je pense aussi à cette autre d...e qu'est word qui détruit parfois son fichier prototype normal.dot.... et y'en a surement d'autre.

pour autocad, il fait des bak lors des sauvegarde de l'utilisateur et il crée des sauvegarde auto (quand elle sont activées) dans le dossier temp de l'utilisateur. ça limite la perte des données, de plus le format dwg contient tout un tas de crc pour protéger son intégrité...

pat

[case]

normalement en lecture tu ne peux pas endommager un fichier ou alors c'est un problème matériel,disque dur non fiable a changer d'urgence.

je part du principe que tu exclus de tes question tout risque exterieur comme la foudre ou une coupure de courant en plein milieu d'une sauvegarde.

Y-a t'il des risques lors de la troncature du fichier d'endommager les données
se situant au dessus ?

si par au dessus tu entends les données écrite entre le début du fichier et l'endroit ou tu tronque celui ci, la réponse est non. tu ne perd que les données situées après.


une bonne idée serait lors de la sauvegarde d'effectuer une copie du fichier précédant en changeant son extension, par exemple .bak pour "backup"

pour être sur de l’intégralité d'une sauvegarde pour justement paré a tout risque de problème du a une coupure de courant par exemple serait de réserver un octet en début de fichier et lors de la sauvegarde le passer a 0
a la fin de la sauvegarde tu le passe a 1.

ainsi lorsque tu charge un fichier si cet octet est a 0 ton programme sait que la sauvegarde est incomplète.
ensuite a toi de voir si tu propose de récupérer la version précédente ( .BAK ) de tenter de récupérer le maximum du contenu et de le rajouté a la sauvegarde précédente etc... etc...

reprend moi si je me trompe.

pour créer ton archive tu prend une arborescence de dossiers et de fichiers et tu sauvegarde tout les fichiers a la suite les un des autres sans séparation. et a la fin tu crée un bloc dans lequel tu stock les adresses et les chemins d’accès

pourquoi tu ne fait pas plutôt quelque chose comme ça.


header pour chaque fichier
--------------------------
integer : taille fichier
string : path
string : nom du fichier
string : commentaires
data : données du fichier

comme ça chaque fichier peut être ressorti d’après les infos dans le header.

de plus au lieu de stocker les dossiers vides tu vérifie juste lors de l’écriture sur le disque que le dossier existe si il n'existe pas tu crée le dossier. et tu sauve le fichier.
exemple pour la sauvegarde
on considère que le fichier est deja ouvert

Code : Tout sélectionner

 WriteInteger(wr,filesize)    
 WriteStringN(wr,path)  ; exemple "mondossier\monfichier.txt"
 WriteStringN(wr,commentaires)
 WriteData(wr,*source,MemorySize(*source))

pour la lecture

Code : Tout sélectionner

  filesize.i= ReadInteger(rd)
  fullpath.s=ReadString(rd)
  path.s=GetPathPart(fullpath)
      If Left(path,1)="\"
         path=Right(path,Len(path)-1)
      EndIf
      If path<>""
         For a = 1 To CountString(path,"\")
            chk$+"\"+StringField(path,a,"\")
            If Left(chk$,1)="\"
               chk$=Right(chk$,Len(chk$)-1)
            EndIf
            If FileSize(chk$)=-1        
              CreateDirectory(chk$)
            EndIf
         Next
      EndIf
  commentaires.s=ReadString(rd)
  *dest=AllocateMemory(filesize)
   ReadData(rd,*dest,filesize)
  wr=createfile(fullpath)
 WriteData(wr,*dest,filesize)
 Freememory(*dest)
CloseFile(wr)

chaque fichier est extrait a la suite, les dossiers sont recrées a la volée pas de problèmes si il manque un bout de fichier les fichiers situes avant peuvent être récupérés.

pour extraire un fichier en particulier, rien de plus simple... ( ouvrir le fichier avec OpenFile() au lieu de ReadFile())

Code : Tout sélectionner

  filesize.i= ReadInteger(rd)
  fullpath.s=ReadString(rd)
  commentaires.s=ReadString(rd)
  if fullpath=fichier_recherche
       *dest=AllocateMemory(filesize)
       ReadData(rd,*dest,filesize)
  else
      FileSeek(rd,loc(rd)+filesize) ; on vas au début du fichier suivant
   endif

[djes]

+1 avec case. Les systèmes de fichiers modernes ont plusieurs copies du catalogue. Une générale et "rapide" en début ou en fin, avec une copie de sauvegarde, et une structure avant chaque fichier (ou dossier) en cas de crash du catalogue.

Pour connaître l'intégrité des données, tu peux utiliser un système de checksum (somme de contrôle), soit sur l'ensemble des données (lent), soit sur des octets pris tous les n (plus rapide).

Pour ce qui est des crashs, toute appli qui crée un fichier devrait faire un backup ou le proposer en option, vérifier que toutes les opérations sont réalisées (vérifier tous les codes d'erreurs), et si les données sont sensibles, proposer la vérification des fichiers créés.

Pour aller encore plus loin, il existe des checksums qui permettent de recomposer plus ou moins les données éventuellement perdues.

[graph100]

Je trouve difficile de créer des fichiers de backup lors de chaque utilisation, la taille moyenne des fichiers que je créé est de 2Go, en faite, ce n'est pas un fichier
qui est destiné à avoir une vie de lecture / écriture, simplement, de lecture :

son utilisation est plutôt comme suit :

On écrit une fois le fichier
on le lit, on le lit, .......
si ajout de commentaire sur le contenu global du fichier archive alors on tronque après le bloc de fin, puis on réécrit les commentaires.

Le but de mon archive est de stocker des images, en gardant une architecture, généralement comme des Tomes d'une série (BD / Manga).
Donc chaque lecture du fichier est faites lorsque l'utilisateur lit la série, et les commentaires sont à propos de la série.

Pour ce qui est de l'index des fichiers en fin d'archive, j'ai fait cela pour pouvoir récupérer rapidement la liste et l'architecture sans parcourir toute l'archive.
Comme si tu le dis le fonction de troncature ne risque pas d'abimer les données situées avant, je pense que je vais rajouter les commentaires en toute fin d'archive

[case]

ok, mais rien ne t’empêche de tout de même sécuriser l'archive au cas ou... au moins tu met la taille et le dossier/nomdefichier de chaque fichier au début de celui ci. car on ne sait jamais, imagine un utilisateur qui efface par mégarde son archive. il récupère celle ci par la suite avec un logiciel de récupération disque mais elle est incomplète . ou alors un disque dur qui se met a avoir un secteur défectueux au beau du bloc de fin... si ton logiciel a une fonction qui permet d'extraire les fichiers de l'archive sans utilisé son catalogue de fin de bloc ça peut être une bonne chose...

moi j'irais pour un peu des deux si j’étais toi ,)

sinon pour éviter de réécrire tout le temps toute l'archive pourquoi tu n'utiliserais pas un système de blocs pour les commentaires ?
par exemple tu alloue un espace de données de 16K pour les commentaires dans chaque fiche de bd dans un fichier de 2GO 16K par bouquin ça représente rien du tout... si tu dépasse les 16ko de commentaires a ce moment la tu alloue un second bloc de commentaires et tu réecrit le bloc de fin, sinon tu complète dans le bloc

pour idée 1KO ça représente 1024 octets donc 1024 signes voir plus bas

000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000

ca fait deja un beau petit commentaire 1 KO alors 16 tu as le temps de voir venir...

en gros dans ton bloc de fin je rajouterais
octet=nb de blocs
puis 16K*nb de blocs de datas contenant les commentaires.

bon 16K c'est arbitraire j'aurais pu dire 8K ou 256K...

mais tu t'évite bien des réécritures de ton bloc de fin au complet en faisant comme ça...

[graph100]

ça n'est pas une mauvaise idée
je pense que je vais aller dans cette direction la, pour éviter trop de fragmentation sur le disque dur.
Effectivement, vu la taille du fichier global, et le gain de place due à la mise bout à bout des différents fichier et donc l'utilisation complète des clusters, 16ko est négligeable.

Je pense que vu la taille des commentaires que je veux mettre, des blocs de 1ko suffisent (ça utiliserais 2 bloc au grand maximum

Avec en plus les info de chaque fichier dans l'en-tête fichier et un contrôle CRC32 pour détecter les problèmes, ça devrais fonctionner pas trop mal, en cas de soucis.

* je m'y met dès que j'ai suffisamment avancé mon système de bibliothèque (vois mon projet ^^) *

[case]

n'oublie pas de compter les caractères de fin de lignes dans la taille du bloc sinon tu risque de déborder

[graph100]

pas de soucis
je vais utiliser une structure de la forme :

[STRING : nom du commentaire (auteur, nom série, genre, etc ...)]
[LONG : taille du commentaire en mémoire]
[DATA : commentaire]

[case]

regarde du coté de peeks() pratique pour lire des chaines en mémoire