Etant habitué à l'usage de 'xcdroast' sur mon vieux PC de bureau (RH 6.0
avec un graveur TEAC SCSI), j'appréciais particulièrement une fonction de
vérification des cdrom fraîchement gravés.
Aujourd'hui, sur mon portable TP600 (RH 7.2 avec un graveur USB externe),
je grave directement avec mkisofs et cdrecord, dans un souci d'économiser
la place que l'interface graphique xcdroast prendrait sur mon disque. Le
problème, c'est que, parmi les options offertes par cdrecord, je n'ai pas
trouvé quelque chose qui permette la vérification des disques gravés.
Merci d'avance pour toute information pertinente sur cette recherche.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Thibaut Paumard
In article , Bernard wrote:
Bonjour à tous,
Etant habitué à l'usage de 'xcdroast' sur mon vieux PC de bureau (RH 6.0 avec un graveur TEAC SCSI), j'appréciais particulièrement une fonction de vérification des cdrom fraîchement gravés.
Bonjour,
cmp /dev/graveur image.iso
Aujourd'hui, sur mon portable TP600 (RH 7.2 avec un graveur USB externe), je grave directement avec mkisofs et cdrecord, dans un souci d'économiser la place que l'interface graphique xcdroast prendrait sur mon disque.
xcdroast, c'est tout petit...
Cordialement, Thibaut.
In article <pan.2004.06.01.16.07.40.987900.10661@lcpc.fr>, Bernard wrote:
Bonjour à tous,
Etant habitué à l'usage de 'xcdroast' sur mon vieux PC de bureau (RH 6.0
avec un graveur TEAC SCSI), j'appréciais particulièrement une fonction de
vérification des cdrom fraîchement gravés.
Bonjour,
cmp /dev/graveur image.iso
Aujourd'hui, sur mon portable TP600 (RH 7.2 avec un graveur USB externe),
je grave directement avec mkisofs et cdrecord, dans un souci d'économiser
la place que l'interface graphique xcdroast prendrait sur mon disque.
Etant habitué à l'usage de 'xcdroast' sur mon vieux PC de bureau (RH 6.0 avec un graveur TEAC SCSI), j'appréciais particulièrement une fonction de vérification des cdrom fraîchement gravés.
Bonjour,
cmp /dev/graveur image.iso
Aujourd'hui, sur mon portable TP600 (RH 7.2 avec un graveur USB externe), je grave directement avec mkisofs et cdrecord, dans un souci d'économiser la place que l'interface graphique xcdroast prendrait sur mon disque.
xcdroast, c'est tout petit...
Cordialement, Thibaut.
tilt
Bonjour à tous,
Bonjour
Le problème, c'est que, parmi les options offertes par cdrecord, je n'ai pas trouvé quelque chose qui permette la vérification des disques gravés.
Merci d'avance pour toute information pertinente sur cette recherche.
Si c'est des systemes de fichiers que tu grave, essaye la commande md5sum. Elle premet de calculer une somme binaire du fichier d'origne et de la comparer avec la somme binaire exectuée sur le fichier gravé.
Il existe une autre commande qui permet de faire la même chose sur une arboresence mais je ne m'en rappele plus.
md5sum est aussi souvent utilisée pour vérifier l'image iso, avant et apres gravage du disque : C'est parfois plus simple de vérifier toute l'image que fichier par fichier.
Bonjour à tous,
Bonjour
Le problème, c'est que, parmi les options offertes par cdrecord, je n'ai pas
trouvé quelque chose qui permette la vérification des disques gravés.
Merci d'avance pour toute information pertinente sur cette recherche.
Si c'est des systemes de fichiers que tu grave, essaye la commande md5sum.
Elle premet de calculer une somme binaire du fichier d'origne et de la
comparer avec la somme binaire exectuée sur le fichier gravé.
Il existe une autre commande qui permet de faire la même chose sur une
arboresence mais je ne m'en rappele plus.
md5sum est aussi souvent utilisée pour vérifier l'image iso, avant et
apres gravage du disque :
C'est parfois plus simple de vérifier toute l'image que fichier par fichier.
Le problème, c'est que, parmi les options offertes par cdrecord, je n'ai pas trouvé quelque chose qui permette la vérification des disques gravés.
Merci d'avance pour toute information pertinente sur cette recherche.
Si c'est des systemes de fichiers que tu grave, essaye la commande md5sum. Elle premet de calculer une somme binaire du fichier d'origne et de la comparer avec la somme binaire exectuée sur le fichier gravé.
Il existe une autre commande qui permet de faire la même chose sur une arboresence mais je ne m'en rappele plus.
md5sum est aussi souvent utilisée pour vérifier l'image iso, avant et apres gravage du disque : C'est parfois plus simple de vérifier toute l'image que fichier par fichier.
Nicolas George
Thibaut Paumard wrote in message :
cmp /dev/graveur image.iso
Ça va très souvent échouer : la lecture de l'extrême fin d'un CD pose souvent problème, car la tête de lecture n'a plus de piste pour se synchroniser. mkisofs prévoit le coup, en mettant par défaut 300 ko de padding à la fin de l'image : à la relecture, c'est un petit bout de ces 300 ko qui est perdu, ce n'est pas grave.
Thibaut Paumard wrote in message
<slrncbr2rt.bhu.mlotpot.news@pc-paumard.mpe-garching.mpg.de>:
cmp /dev/graveur image.iso
Ça va très souvent échouer : la lecture de l'extrême fin d'un CD pose
souvent problème, car la tête de lecture n'a plus de piste pour se
synchroniser. mkisofs prévoit le coup, en mettant par défaut 300 ko de
padding à la fin de l'image : à la relecture, c'est un petit bout de ces
300 ko qui est perdu, ce n'est pas grave.
Ça va très souvent échouer : la lecture de l'extrême fin d'un CD pose souvent problème, car la tête de lecture n'a plus de piste pour se synchroniser. mkisofs prévoit le coup, en mettant par défaut 300 ko de padding à la fin de l'image : à la relecture, c'est un petit bout de ces 300 ko qui est perdu, ce n'est pas grave.
Thibaut Paumard
In article <c9k72o$260u$, Nicolas George wrote:
Thibaut Paumard wrote in message :
cmp /dev/graveur image.iso
Ça va très souvent échouer : la lecture de l'extrême fin d'un CD pose souvent problème, car la tête de lecture n'a plus de piste pour se synchroniser. mkisofs prévoit le coup, en mettant par défaut 300 ko de padding à la fin de l'image : à la relecture, c'est un petit bout de ces 300 ko qui est perdu, ce n'est pas grave.
Est-ce que cette limitation s'applique aussi pour la méthode du md5sum (Auquel cas j'imagine que c'est pire) ? Quelle est la "bonne" méthode, quelle est celle employée par xcdroast ?
Cordialement, Thibaut.
In article <c9k72o$260u$1@biggoron.nerim.net>, Nicolas George wrote:
Thibaut Paumard wrote in message
<slrncbr2rt.bhu.mlotpot.news@pc-paumard.mpe-garching.mpg.de>:
cmp /dev/graveur image.iso
Ça va très souvent échouer : la lecture de l'extrême fin d'un CD pose
souvent problème, car la tête de lecture n'a plus de piste pour se
synchroniser. mkisofs prévoit le coup, en mettant par défaut 300 ko de
padding à la fin de l'image : à la relecture, c'est un petit bout de ces
300 ko qui est perdu, ce n'est pas grave.
Est-ce que cette limitation s'applique aussi pour la méthode du md5sum
(Auquel cas j'imagine que c'est pire) ? Quelle est la "bonne" méthode,
quelle est celle employée par xcdroast ?
Ça va très souvent échouer : la lecture de l'extrême fin d'un CD pose souvent problème, car la tête de lecture n'a plus de piste pour se synchroniser. mkisofs prévoit le coup, en mettant par défaut 300 ko de padding à la fin de l'image : à la relecture, c'est un petit bout de ces 300 ko qui est perdu, ce n'est pas grave.
Est-ce que cette limitation s'applique aussi pour la méthode du md5sum (Auquel cas j'imagine que c'est pire) ? Quelle est la "bonne" méthode, quelle est celle employée par xcdroast ?
Cordialement, Thibaut.
Nicolas George
Thibaut Paumard wrote in message :
Est-ce que cette limitation s'applique aussi pour la méthode du md5sum
Ça dépend comment on l'applique. Ce qui va certainement arriver, c'est que fichier.iso != données lues sur /dev/cdrom. La conséquence est _probablement_ que md5(fichier.iso) != md5(/dev/cdrom), puisque md5 est « pratiquement injective ». En revanche, si on applique md5 à chaque fichier, une fois dans l'image montée en loopback, une fois sur le CD monté, ça devrait donner la même chose, puisque ce ne sont que des données inutiles, en dehors de tout fichier, qui sont touchées.
Quelle est la "bonne" méthode,
Hum, c'est une vaste question. Je dirais que le mieux serait d'utiliser isoinfo -d pour déterminer la taille théorique de l'image (Volume size, par blocs de 2 ko), puis d'utiliser quelque chose comme
Il peut être utile de vérifier que les données lues sur /dev/cdrom perdent moins de 300 ko par rapport à la taille théorique ; alternativement, on peut utiliser isoinfo -l pour vérifier que tous les fichiers sont à l'intérieur de la zone correctement relue (le premier nombre entre crochets est le secteur où commence le fichier, si je ne me trompe).
Personnellement, quand je grave en mono-session, je fais toujours :
dd if=/dev/urandom bs=1M count=8 >> image.iso
avant (parfois moins que 8 Mo, si l'image est déjà bien pleine). Dans ce cas, l'image entière reste disponible, et il suffit de vérifier le md5 avec
dd if=/dev/cdrom bs=2k count=$n | md5sum
On pourrait aussi mettre du /dev/zero plutôt que du /dev/urandom, mais le /dev/urandom ça fait stresser la NSA.
quelle est celle employée par xcdroast ?
Aucune idée.
Thibaut Paumard wrote in message
<slrncbr9f2.c2l.mlotpot.news@pc-paumard.mpe-garching.mpg.de>:
Est-ce que cette limitation s'applique aussi pour la méthode du md5sum
Ça dépend comment on l'applique. Ce qui va certainement arriver, c'est
que fichier.iso != données lues sur /dev/cdrom. La conséquence est
_probablement_ que md5(fichier.iso) != md5(/dev/cdrom), puisque md5 est
« pratiquement injective ». En revanche, si on applique md5 à chaque
fichier, une fois dans l'image montée en loopback, une fois sur le CD
monté, ça devrait donner la même chose, puisque ce ne sont que des
données inutiles, en dehors de tout fichier, qui sont touchées.
Quelle est la "bonne" méthode,
Hum, c'est une vaste question. Je dirais que le mieux serait d'utiliser
isoinfo -d pour déterminer la taille théorique de l'image (Volume size,
par blocs de 2 ko), puis d'utiliser quelque chose comme
Il peut être utile de vérifier que les données lues sur /dev/cdrom
perdent moins de 300 ko par rapport à la taille théorique ;
alternativement, on peut utiliser isoinfo -l pour vérifier que tous les
fichiers sont à l'intérieur de la zone correctement relue (le premier
nombre entre crochets est le secteur où commence le fichier, si je ne me
trompe).
Personnellement, quand je grave en mono-session, je fais toujours :
dd if=/dev/urandom bs=1M count=8 >> image.iso
avant (parfois moins que 8 Mo, si l'image est déjà bien pleine). Dans ce
cas, l'image entière reste disponible, et il suffit de vérifier le md5
avec
dd if=/dev/cdrom bs=2k count=$n | md5sum
On pourrait aussi mettre du /dev/zero plutôt que du /dev/urandom, mais
le /dev/urandom ça fait stresser la NSA.
Est-ce que cette limitation s'applique aussi pour la méthode du md5sum
Ça dépend comment on l'applique. Ce qui va certainement arriver, c'est que fichier.iso != données lues sur /dev/cdrom. La conséquence est _probablement_ que md5(fichier.iso) != md5(/dev/cdrom), puisque md5 est « pratiquement injective ». En revanche, si on applique md5 à chaque fichier, une fois dans l'image montée en loopback, une fois sur le CD monté, ça devrait donner la même chose, puisque ce ne sont que des données inutiles, en dehors de tout fichier, qui sont touchées.
Quelle est la "bonne" méthode,
Hum, c'est une vaste question. Je dirais que le mieux serait d'utiliser isoinfo -d pour déterminer la taille théorique de l'image (Volume size, par blocs de 2 ko), puis d'utiliser quelque chose comme
Il peut être utile de vérifier que les données lues sur /dev/cdrom perdent moins de 300 ko par rapport à la taille théorique ; alternativement, on peut utiliser isoinfo -l pour vérifier que tous les fichiers sont à l'intérieur de la zone correctement relue (le premier nombre entre crochets est le secteur où commence le fichier, si je ne me trompe).
Personnellement, quand je grave en mono-session, je fais toujours :
dd if=/dev/urandom bs=1M count=8 >> image.iso
avant (parfois moins que 8 Mo, si l'image est déjà bien pleine). Dans ce cas, l'image entière reste disponible, et il suffit de vérifier le md5 avec
dd if=/dev/cdrom bs=2k count=$n | md5sum
On pourrait aussi mettre du /dev/zero plutôt que du /dev/urandom, mais le /dev/urandom ça fait stresser la NSA.
quelle est celle employée par xcdroast ?
Aucune idée.
Bernard
On Wed, 02 Jun 2004 10:10:37 +0200, Thibaut Paumard wrote:
In article , Bernard wrote:
Bonjour à tous,
Etant habitué à l'usage de 'xcdroast' sur mon vieux PC de bureau (RH 6.0 avec un graveur TEAC SCSI), j'appréciais particulièrement une fonction de vérification des cdrom fraîchement gravés.
Bonjour,
cmp /dev/graveur image.iso
Aujourd'hui, sur mon portable TP600 (RH 7.2 avec un graveur USB externe), je grave directement avec mkisofs et cdrecord, dans un souci d'économiser la place que l'interface graphique xcdroast prendrait sur mon disque.
xcdroast, c'est tout petit...
Cordialement, Thibaut.
J'ai donc le choix entre diff, cmp et md5sum. Je vais d'abord commencer par essayer diff, ce qui me paraît le plus simple à utiliser :
diff -r répertoire1 répertoire2
Comme l'option de récursivité ne paraît pas exister dans cmp et md5sum, il serait nécessaire d'écrire des scripts avec des boucles. Je viens d'essayer diff de cette façon pour comparer deux répertoires identiques, puis après y avoir mis quelques différences mineures, et çà a paru satisfaisant. Reste à savoir ce que je vais trouver avec mes iso images et les fichiers gravés sur cdrom...
On Wed, 02 Jun 2004 10:10:37 +0200, Thibaut Paumard wrote:
In article <pan.2004.06.01.16.07.40.987900.10661@lcpc.fr>, Bernard
wrote:
Bonjour à tous,
Etant habitué à l'usage de 'xcdroast' sur mon vieux PC de bureau (RH
6.0 avec un graveur TEAC SCSI), j'appréciais particulièrement une
fonction de vérification des cdrom fraîchement gravés.
Bonjour,
cmp /dev/graveur image.iso
Aujourd'hui, sur mon portable TP600 (RH 7.2 avec un graveur USB
externe), je grave directement avec mkisofs et cdrecord, dans un souci
d'économiser la place que l'interface graphique xcdroast prendrait sur
mon disque.
xcdroast, c'est tout petit...
Cordialement, Thibaut.
J'ai donc le choix entre diff, cmp et md5sum. Je vais d'abord commencer
par essayer diff, ce qui me paraît le plus simple à utiliser :
diff -r répertoire1 répertoire2
Comme l'option de récursivité ne paraît pas exister dans cmp et md5sum, il
serait nécessaire d'écrire des scripts avec des boucles. Je viens
d'essayer diff de cette façon pour comparer deux répertoires identiques,
puis après y avoir mis quelques différences mineures, et çà a paru
satisfaisant. Reste à savoir ce que je vais trouver avec mes iso images et
les fichiers gravés sur cdrom...
On Wed, 02 Jun 2004 10:10:37 +0200, Thibaut Paumard wrote:
In article , Bernard wrote:
Bonjour à tous,
Etant habitué à l'usage de 'xcdroast' sur mon vieux PC de bureau (RH 6.0 avec un graveur TEAC SCSI), j'appréciais particulièrement une fonction de vérification des cdrom fraîchement gravés.
Bonjour,
cmp /dev/graveur image.iso
Aujourd'hui, sur mon portable TP600 (RH 7.2 avec un graveur USB externe), je grave directement avec mkisofs et cdrecord, dans un souci d'économiser la place que l'interface graphique xcdroast prendrait sur mon disque.
xcdroast, c'est tout petit...
Cordialement, Thibaut.
J'ai donc le choix entre diff, cmp et md5sum. Je vais d'abord commencer par essayer diff, ce qui me paraît le plus simple à utiliser :
diff -r répertoire1 répertoire2
Comme l'option de récursivité ne paraît pas exister dans cmp et md5sum, il serait nécessaire d'écrire des scripts avec des boucles. Je viens d'essayer diff de cette façon pour comparer deux répertoires identiques, puis après y avoir mis quelques différences mineures, et çà a paru satisfaisant. Reste à savoir ce que je vais trouver avec mes iso images et les fichiers gravés sur cdrom...
Thibaut Paumard
In article , Bernard wrote:
On Wed, 02 Jun 2004 10:10:37 +0200, Thibaut Paumard wrote:
In article , Bernard wrote:
Bonjour à tous,
Etant habitué à l'usage de 'xcdroast' sur mon vieux PC de bureau (RH 6.0 avec un graveur TEAC SCSI), j'appréciais particulièrement une fonction de vérification des cdrom fraîchement gravés.
Bonjour,
cmp /dev/graveur image.iso
[...]
Comme l'option de récursivité ne paraît pas exister dans cmp et md5sum
Bonjour,
je parlait de comparer directement le contenu du CD et l'image iso, donc un seul (gros) fichier, donc pas besoin de récursivité... Je pense que c'est plus rapide de procéder comme ça.
Cordialement, Thibaut.
In article <pan.2004.06.02.11.54.17.243343.1832@lcpc.fr>, Bernard wrote:
On Wed, 02 Jun 2004 10:10:37 +0200, Thibaut Paumard wrote:
In article <pan.2004.06.01.16.07.40.987900.10661@lcpc.fr>, Bernard
wrote:
Bonjour à tous,
Etant habitué à l'usage de 'xcdroast' sur mon vieux PC de bureau (RH
6.0 avec un graveur TEAC SCSI), j'appréciais particulièrement une
fonction de vérification des cdrom fraîchement gravés.
Bonjour,
cmp /dev/graveur image.iso
[...]
Comme l'option de récursivité ne paraît pas exister dans cmp et md5sum
Bonjour,
je parlait de comparer directement le contenu du CD et l'image iso, donc un
seul (gros) fichier, donc pas besoin de récursivité... Je pense que c'est
plus rapide de procéder comme ça.
On Wed, 02 Jun 2004 10:10:37 +0200, Thibaut Paumard wrote:
In article , Bernard wrote:
Bonjour à tous,
Etant habitué à l'usage de 'xcdroast' sur mon vieux PC de bureau (RH 6.0 avec un graveur TEAC SCSI), j'appréciais particulièrement une fonction de vérification des cdrom fraîchement gravés.
Bonjour,
cmp /dev/graveur image.iso
[...]
Comme l'option de récursivité ne paraît pas exister dans cmp et md5sum
Bonjour,
je parlait de comparer directement le contenu du CD et l'image iso, donc un seul (gros) fichier, donc pas besoin de récursivité... Je pense que c'est plus rapide de procéder comme ça.
Cordialement, Thibaut.
Bernard
On Wed, 02 Jun 2004 11:36:24 +0200, Nicolas George wrote:
Thibaut Paumard wrote in message :
cmp /dev/graveur image.iso
Ça va très souvent échouer : la lecture de l'extrême fin d'un CD pose souvent problème, car la tête de lecture n'a plus de piste pour se synchroniser. mkisofs prévoit le coup, en mettant par défaut 300 ko de padding à la fin de l'image : à la relecture, c'est un petit bout de ces 300 ko qui est perdu, ce n'est pas grave.
Je viens de faire quelques essais avec diff -r, et çà a fonctionné étonnemment bien ! Mais il est vrai qu'il s'agissait d'un répertoire (avec sous dossiers) d'environ 15 MB seulement. Je referai l'essai avec un disque pratiquement rempli (650 MB) pour pouvoir mieux apprécier la fiabilité du procédé, et aussi sa durée.
On Wed, 02 Jun 2004 11:36:24 +0200, Nicolas George wrote:
Thibaut Paumard wrote in message
<slrncbr2rt.bhu.mlotpot.news@pc-paumard.mpe-garching.mpg.de>:
cmp /dev/graveur image.iso
Ça va très souvent échouer : la lecture de l'extrême fin d'un CD pose
souvent problème, car la tête de lecture n'a plus de piste pour se
synchroniser. mkisofs prévoit le coup, en mettant par défaut 300 ko de
padding à la fin de l'image : à la relecture, c'est un petit bout de ces
300 ko qui est perdu, ce n'est pas grave.
Je viens de faire quelques essais avec diff -r, et çà a fonctionné
étonnemment bien ! Mais il est vrai qu'il s'agissait d'un répertoire
(avec sous dossiers)
d'environ 15 MB seulement. Je referai l'essai avec un disque pratiquement
rempli (650 MB) pour pouvoir mieux apprécier la fiabilité du procédé, et
aussi sa durée.
On Wed, 02 Jun 2004 11:36:24 +0200, Nicolas George wrote:
Thibaut Paumard wrote in message :
cmp /dev/graveur image.iso
Ça va très souvent échouer : la lecture de l'extrême fin d'un CD pose souvent problème, car la tête de lecture n'a plus de piste pour se synchroniser. mkisofs prévoit le coup, en mettant par défaut 300 ko de padding à la fin de l'image : à la relecture, c'est un petit bout de ces 300 ko qui est perdu, ce n'est pas grave.
Je viens de faire quelques essais avec diff -r, et çà a fonctionné étonnemment bien ! Mais il est vrai qu'il s'agissait d'un répertoire (avec sous dossiers) d'environ 15 MB seulement. Je referai l'essai avec un disque pratiquement rempli (650 MB) pour pouvoir mieux apprécier la fiabilité du procédé, et aussi sa durée.
Nicolas George
Bernard wrote in message :
Je viens de faire quelques essais avec diff -r, et çà a fonctionné étonnemment bien ! Mais il est vrai qu'il s'agissait d'un répertoire (avec sous dossiers) d'environ 15 MB seulement.
Rien à voir. Une image ISO, c'est quelque chose comme ça :
Le résultat n'est pas identique à l'original, mais le remplissage est précisément prévu pour qu'aucun fichier ne soit touché, donc sans importance.
Bernard wrote in message <pan.2004.06.03.09.08.54.523214.1462@lcpc.fr>:
Je viens de faire quelques essais avec diff -r, et çà a fonctionné
étonnemment bien ! Mais il est vrai qu'il s'agissait d'un répertoire
(avec sous dossiers) d'environ 15 MB seulement.
Rien à voir. Une image ISO, c'est quelque chose comme ça :
Je viens de faire quelques essais avec diff -r, et çà a fonctionné étonnemment bien ! Mais il est vrai qu'il s'agissait d'un répertoire (avec sous dossiers) d'environ 15 MB seulement.
Rien à voir. Une image ISO, c'est quelque chose comme ça :
