les crc sont pas dans l'image iso mais sur le support physique.
par contre, non, le filessytem iso9660 n'est pas fait pour etre modifier a la volee, donc le proposer serait complexe a programmer et particulierement peu performant.
sans compter que de base iso9660 est un sac de noeuds.
en substance:
dans un fs fait pour la lecture ecriture, on laisse de la place a droite a gauche pour pouvoir ajouter des choses au fur et a mesure (et sur les filesystem microsoft en plus on s'arrange pour que ca fasse des trous durables dans le temps pour obliger les gens a defragmenter mais c'est une autre histoire).
sur un fs destine a de la lecture seule, comme iso9660 ou romfs (cat /usr/src/linux/Documentation/filesystems/romfs.txt pour plus d'info), on met la liste de tous les fichiers une fois pour toute au debut du filesystem et on tasse tout pour ne pas perdre de place. du coup si tu veux ajouter des fichiers ou les agrandir, il faut deplacer tous les autres (donc il faut beaucoup reflechir pour voir comment faire et en plus ca peut revenir a deplacer plusieurs centaines de Mo pour ajouter 3 octets), ca sera beaucoup plus lent que de refaire l'image iso, des lors que tu ajouteras quelques dizaines de fichiers.
(je simplifie un peu)
par contre on peut imaginer des truc tres sioux genre un pseudo-filesystem qui stocke les donnees en ext2 quand tu les ecrits, et qui, lorsque tu demonte le filesystem (unmount) genere l'image iso pour toi, tu auras le meme confort. cela dit c'est bien complique, et ca revient a la meme chose que de stocker dans un repertoire puis d'appeler mkisofs...
si ton probleme c'est que tu trouves mkisofs tres lent, achete 2 barrettes de 512Mo, une fois que tous les fichiers a mettre dans l'image iso sont en cache, mkisofs est bcp plus rapide... un dur performant aide aussi.
[^] # Re: Lecture / ecriture
Posté par barbie_g . En réponse au message [Terminal] Monter des images ISO. Évalué à 1.
par contre, non, le filessytem iso9660 n'est pas fait pour etre modifier a la volee, donc le proposer serait complexe a programmer et particulierement peu performant.
sans compter que de base iso9660 est un sac de noeuds.
en substance:
dans un fs fait pour la lecture ecriture, on laisse de la place a droite a gauche pour pouvoir ajouter des choses au fur et a mesure (et sur les filesystem microsoft en plus on s'arrange pour que ca fasse des trous durables dans le temps pour obliger les gens a defragmenter mais c'est une autre histoire).
sur un fs destine a de la lecture seule, comme iso9660 ou romfs (cat /usr/src/linux/Documentation/filesystems/romfs.txt pour plus d'info), on met la liste de tous les fichiers une fois pour toute au debut du filesystem et on tasse tout pour ne pas perdre de place. du coup si tu veux ajouter des fichiers ou les agrandir, il faut deplacer tous les autres (donc il faut beaucoup reflechir pour voir comment faire et en plus ca peut revenir a deplacer plusieurs centaines de Mo pour ajouter 3 octets), ca sera beaucoup plus lent que de refaire l'image iso, des lors que tu ajouteras quelques dizaines de fichiers.
(je simplifie un peu)
par contre on peut imaginer des truc tres sioux genre un pseudo-filesystem qui stocke les donnees en ext2 quand tu les ecrits, et qui, lorsque tu demonte le filesystem (unmount) genere l'image iso pour toi, tu auras le meme confort. cela dit c'est bien complique, et ca revient a la meme chose que de stocker dans un repertoire puis d'appeler mkisofs...
si ton probleme c'est que tu trouves mkisofs tres lent, achete 2 barrettes de 512Mo, une fois que tous les fichiers a mettre dans l'image iso sont en cache, mkisofs est bcp plus rapide... un dur performant aide aussi.
si tu n'es pas motive pour aller voir le code source de mkisofs (par exemple), tu peux jeter un coup d'oeil la:
http://www.alumni.caltech.edu/~pje/iso9660.html(...)