Obtenir d'un DVD une image sous forme d'un fichier
16 réponses
Francois Lafont
Bonjour à tous,
J'ai un DVD. Est-il possible d'en obtenir un fichier .iso ? Sur ma
Debian Squeeze avec Brasero, c'est impossible : « Veuillez remplacer le
disque par un CD ou un DVD pris en charge ». Manifestement mon DVD est
au format UDF (il porte le nom « UDF Volume ») et j'ai l'impression que
c'est ça qui coince. J'avoue ne pas y connaître grand chose dans ce domaine.
Dans l'idéal, ce que je souhaiterais, c'est de pouvoir faire de mon DVD
une image .iso que je puisse insérer dans une machine virtuelle
VirtualBox comme un « cd virtuel ». Est-ce possible et comment ?
Francois Lafont , dans le message <4e218dfa$0$32650$, a écrit :
J'ai un DVD. Est-il possible d'en obtenir un fichier .iso ?
Sauf complications, ceci devrait suffire :
cp /dev/dvd image.iso
Si ça ne marche pas, il faudra que tu en dises plus sur les détails.
Francois Lafont
Le 16/07/2011 15:29, Nicolas George a écrit :
Sauf complications, ceci devrait suffire :
cp /dev/dvd image.iso
Et bien ça marche. En fait, le DVD correspondait à /dev/sr0 d'après les informations données par la commande mount et un simple « cp /dev/sr0 image.iso » (qui a duré une vingtaine de minutes en gros) et j'ai obtenu une image iso qui fonctionne très bien. Au passage, je suis étonné de la simplicité de la commande : derrière les conversions .iso que je faisais avec Brasero se cachait une simple commande cp !
Mon problème est résolu. Merci beaucoup Nicolas. :-)
Désolé, mais du coup, j'ai quand même une petite question existentielle qui me taraude, bien que le fil soit résolu.
Supposons que j'ai deux disques durs physiquement identiques (mais pas forcément identiques au niveau de leur contenu) /dev/sdb et /dev/sdc constitués tous les deux d'une seule partition en ext3 par exemple et chacun monté respectivement sur /mnt/b/ et /mnt/c/. Quelle est la différence entre :
1) un truc du genre # cp -Rf /mnt/b/ /mnt/c/
2) et un truc du genre # cat /dev/b > /dev/c
?
Les commandes 1 et 2 ne sont sûrement pas tout à fait correctes, mais vous voyez l'idée de ma question je pense. Je sais que ce n'est pas équivalent dans les faits, mais pourquoi exactement ? Je me suis souvent posé la question.
-- François Lafont
Le 16/07/2011 15:29, Nicolas George a écrit :
Sauf complications, ceci devrait suffire :
cp /dev/dvd image.iso
Et bien ça marche. En fait, le DVD correspondait à /dev/sr0 d'après les
informations données par la commande mount et un simple « cp /dev/sr0
image.iso » (qui a duré une vingtaine de minutes en gros) et j'ai obtenu
une image iso qui fonctionne très bien. Au passage, je suis étonné de la
simplicité de la commande : derrière les conversions .iso que je faisais
avec Brasero se cachait une simple commande cp !
Mon problème est résolu. Merci beaucoup Nicolas. :-)
Désolé, mais du coup, j'ai quand même une petite question existentielle
qui me taraude, bien que le fil soit résolu.
Supposons que j'ai deux disques durs physiquement identiques (mais pas
forcément identiques au niveau de leur contenu) /dev/sdb et /dev/sdc
constitués tous les deux d'une seule partition en ext3 par exemple et
chacun monté respectivement sur /mnt/b/ et /mnt/c/. Quelle est la
différence entre :
1) un truc du genre
# cp -Rf /mnt/b/ /mnt/c/
2) et un truc du genre
# cat /dev/b > /dev/c
?
Les commandes 1 et 2 ne sont sûrement pas tout à fait correctes, mais
vous voyez l'idée de ma question je pense. Je sais que ce n'est pas
équivalent dans les faits, mais pourquoi exactement ? Je me suis souvent
posé la question.
Et bien ça marche. En fait, le DVD correspondait à /dev/sr0 d'après les informations données par la commande mount et un simple « cp /dev/sr0 image.iso » (qui a duré une vingtaine de minutes en gros) et j'ai obtenu une image iso qui fonctionne très bien. Au passage, je suis étonné de la simplicité de la commande : derrière les conversions .iso que je faisais avec Brasero se cachait une simple commande cp !
Mon problème est résolu. Merci beaucoup Nicolas. :-)
Désolé, mais du coup, j'ai quand même une petite question existentielle qui me taraude, bien que le fil soit résolu.
Supposons que j'ai deux disques durs physiquement identiques (mais pas forcément identiques au niveau de leur contenu) /dev/sdb et /dev/sdc constitués tous les deux d'une seule partition en ext3 par exemple et chacun monté respectivement sur /mnt/b/ et /mnt/c/. Quelle est la différence entre :
1) un truc du genre # cp -Rf /mnt/b/ /mnt/c/
2) et un truc du genre # cat /dev/b > /dev/c
?
Les commandes 1 et 2 ne sont sûrement pas tout à fait correctes, mais vous voyez l'idée de ma question je pense. Je sais que ce n'est pas équivalent dans les faits, mais pourquoi exactement ? Je me suis souvent posé la question.
-- François Lafont
Nicolas George
Francois Lafont , dans le message <4e219fd2$0$6036$, a écrit :
En fait, le DVD correspondait à /dev/sr0 d'après les informations données par la commande mount
Les distributions prévoient en général un lien symbolique pour que le lecteur optique apparaisse en tant que /dev/dvd quelle que soit la manière dont il est connecté.
1) un truc du genre # cp -Rf /mnt/b/ /mnt/c/
Cette opération lit chaque fichier du disque source, crée le fichier correspondant sur le disque cible, et recommence.
Lire un fichier veut dire demander à l'OS de décoder les secteurs qui décrivent la structure du disque (correspondance entre nom de fichier et permissions, taille et position sur disque), puis de lire les secteurs correspondant aux données du fichier.
Écrire un fichier veut dire demander à l'OS d'allouer des secteurs encore inutilisés, et les enregistrer comme utilisés, associés à un nom.
Notons que cette commande ne copie pas les permissions des fichiers, mais des options de cp peuvent y remédier.
2) et un truc du genre # cat /dev/b > /dev/c
Cette opération copie tous les secteurs d'un disque à l'autre.
Les différences sont nombreuses, et la lsite que je vais faire n'est pas du tout exhaustive :
- Si b est très peu rempli, (1) est très largement plus rapide que (2).
- Si b est très rempli et très fragmenté (beaucoup de petits fichiers crées dans le désordre, ou fichiers remplis dans le désordre (P2P par exemple)), (2) sera largement plus rapide que (1) parce que ça lit le disque dans l'ordre des secteurs et pas dans l'ordre des fichiers. C'est valable si le disque est mécanique, pas pour du SSD.
- A contrario, après copie par (1), les fichiers de c ne seront pas du tout fragmentés, alors qu'une copie par (2) gardera cette caractéristique.
- (2) prserve les métadonnées des fichiers même si elles ne sont pas prises en charge par cp ou l'OS. C'est valable en particulier pour le ctime, qu'il est impossible de positionner explicitement.
- Si tu fais (2) sans démonter c ou en écrivant sur b en même temps, ça va faire des dégâts.
- Avec (2), les données globales du disque, comme son label ou son UUID, sont copiés aussi.
- Avec (2), on copie l'espace inutilisé, ce qui peut être utile (on peut cacher des données dans l'espace inutilisé) ou néfaste (si on a effacé des données compromettantes de b, et qu'on compte le détruire physiquement après copie).
- Avec (1), il n'y a aucune exigence que b et c utilisent le même filesystem. Avec (2), le filesystem qui était précédemment présent sur c est ignoré et remplacé par celui de b.
- S'il y a des secteurs défectueux qui ont été repérés sur b, (2) va copier la table de secteurs défectueux, alors même que c n'en a pas. Réciproquement, s'il y a des secteurs défectueux sur c, ça posera des problèmes de copie.
- Si b et c n'ont pas exactement la même taille, ça ne va pas bien coller. Si c est plus gros, c'est juste un peu de place perdue, si b est plus gros on court à la catastrophe.
Personnellement, je déconseille très fortement la copie de device à device d'un disque dur, ce n'est que très rarement une bonne idée.
Francois Lafont , dans le message
<4e219fd2$0$6036$426a34cc@news.free.fr>, a écrit :
En fait, le DVD correspondait à /dev/sr0 d'après les
informations données par la commande mount
Les distributions prévoient en général un lien symbolique pour que le
lecteur optique apparaisse en tant que /dev/dvd quelle que soit la manière
dont il est connecté.
1) un truc du genre
# cp -Rf /mnt/b/ /mnt/c/
Cette opération lit chaque fichier du disque source, crée le fichier
correspondant sur le disque cible, et recommence.
Lire un fichier veut dire demander à l'OS de décoder les secteurs qui
décrivent la structure du disque (correspondance entre nom de fichier et
permissions, taille et position sur disque), puis de lire les secteurs
correspondant aux données du fichier.
Écrire un fichier veut dire demander à l'OS d'allouer des secteurs encore
inutilisés, et les enregistrer comme utilisés, associés à un nom.
Notons que cette commande ne copie pas les permissions des fichiers, mais
des options de cp peuvent y remédier.
2) et un truc du genre
# cat /dev/b > /dev/c
Cette opération copie tous les secteurs d'un disque à l'autre.
Les différences sont nombreuses, et la lsite que je vais faire n'est pas du
tout exhaustive :
- Si b est très peu rempli, (1) est très largement plus rapide que (2).
- Si b est très rempli et très fragmenté (beaucoup de petits fichiers crées
dans le désordre, ou fichiers remplis dans le désordre (P2P par exemple)),
(2) sera largement plus rapide que (1) parce que ça lit le disque dans
l'ordre des secteurs et pas dans l'ordre des fichiers. C'est valable si le
disque est mécanique, pas pour du SSD.
- A contrario, après copie par (1), les fichiers de c ne seront pas du tout
fragmentés, alors qu'une copie par (2) gardera cette caractéristique.
- (2) prserve les métadonnées des fichiers même si elles ne sont pas prises
en charge par cp ou l'OS. C'est valable en particulier pour le ctime,
qu'il est impossible de positionner explicitement.
- Si tu fais (2) sans démonter c ou en écrivant sur b en même temps, ça va
faire des dégâts.
- Avec (2), les données globales du disque, comme son label ou son UUID,
sont copiés aussi.
- Avec (2), on copie l'espace inutilisé, ce qui peut être utile (on peut
cacher des données dans l'espace inutilisé) ou néfaste (si on a effacé des
données compromettantes de b, et qu'on compte le détruire physiquement
après copie).
- Avec (1), il n'y a aucune exigence que b et c utilisent le même
filesystem. Avec (2), le filesystem qui était précédemment présent sur c
est ignoré et remplacé par celui de b.
- S'il y a des secteurs défectueux qui ont été repérés sur b, (2) va copier
la table de secteurs défectueux, alors même que c n'en a pas.
Réciproquement, s'il y a des secteurs défectueux sur c, ça posera des
problèmes de copie.
- Si b et c n'ont pas exactement la même taille, ça ne va pas bien coller.
Si c est plus gros, c'est juste un peu de place perdue, si b est plus gros
on court à la catastrophe.
Personnellement, je déconseille très fortement la copie de device à device
d'un disque dur, ce n'est que très rarement une bonne idée.
Francois Lafont , dans le message <4e219fd2$0$6036$, a écrit :
En fait, le DVD correspondait à /dev/sr0 d'après les informations données par la commande mount
Les distributions prévoient en général un lien symbolique pour que le lecteur optique apparaisse en tant que /dev/dvd quelle que soit la manière dont il est connecté.
1) un truc du genre # cp -Rf /mnt/b/ /mnt/c/
Cette opération lit chaque fichier du disque source, crée le fichier correspondant sur le disque cible, et recommence.
Lire un fichier veut dire demander à l'OS de décoder les secteurs qui décrivent la structure du disque (correspondance entre nom de fichier et permissions, taille et position sur disque), puis de lire les secteurs correspondant aux données du fichier.
Écrire un fichier veut dire demander à l'OS d'allouer des secteurs encore inutilisés, et les enregistrer comme utilisés, associés à un nom.
Notons que cette commande ne copie pas les permissions des fichiers, mais des options de cp peuvent y remédier.
2) et un truc du genre # cat /dev/b > /dev/c
Cette opération copie tous les secteurs d'un disque à l'autre.
Les différences sont nombreuses, et la lsite que je vais faire n'est pas du tout exhaustive :
- Si b est très peu rempli, (1) est très largement plus rapide que (2).
- Si b est très rempli et très fragmenté (beaucoup de petits fichiers crées dans le désordre, ou fichiers remplis dans le désordre (P2P par exemple)), (2) sera largement plus rapide que (1) parce que ça lit le disque dans l'ordre des secteurs et pas dans l'ordre des fichiers. C'est valable si le disque est mécanique, pas pour du SSD.
- A contrario, après copie par (1), les fichiers de c ne seront pas du tout fragmentés, alors qu'une copie par (2) gardera cette caractéristique.
- (2) prserve les métadonnées des fichiers même si elles ne sont pas prises en charge par cp ou l'OS. C'est valable en particulier pour le ctime, qu'il est impossible de positionner explicitement.
- Si tu fais (2) sans démonter c ou en écrivant sur b en même temps, ça va faire des dégâts.
- Avec (2), les données globales du disque, comme son label ou son UUID, sont copiés aussi.
- Avec (2), on copie l'espace inutilisé, ce qui peut être utile (on peut cacher des données dans l'espace inutilisé) ou néfaste (si on a effacé des données compromettantes de b, et qu'on compte le détruire physiquement après copie).
- Avec (1), il n'y a aucune exigence que b et c utilisent le même filesystem. Avec (2), le filesystem qui était précédemment présent sur c est ignoré et remplacé par celui de b.
- S'il y a des secteurs défectueux qui ont été repérés sur b, (2) va copier la table de secteurs défectueux, alors même que c n'en a pas. Réciproquement, s'il y a des secteurs défectueux sur c, ça posera des problèmes de copie.
- Si b et c n'ont pas exactement la même taille, ça ne va pas bien coller. Si c est plus gros, c'est juste un peu de place perdue, si b est plus gros on court à la catastrophe.
Personnellement, je déconseille très fortement la copie de device à device d'un disque dur, ce n'est que très rarement une bonne idée.
Sergio
Le 16/07/2011 16:28, Francois Lafont a écrit :
1) un truc du genre # cp -Rf /mnt/b/ /mnt/c/
2) et un truc du genre # cat /dev/b> /dev/c
?
Pour ça, la commande "dd" semble appropriée...
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 16/07/2011 16:28, Francois Lafont a écrit :
1) un truc du genre
# cp -Rf /mnt/b/ /mnt/c/
2) et un truc du genre
# cat /dev/b> /dev/c
?
Pour ça, la commande "dd" semble appropriée...
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Francois Lafont
Le 16/07/2011 17:09, Nicolas George a écrit :
Les distributions prévoient en général un lien symbolique pour que le lecteur optique apparaisse en tant que /dev/dvd quelle que soit la manière dont il est connecté.
Ok. Je viens de constater que c'est bien le cas sur ma distribution.
1) un truc du genre # cp -Rf /mnt/b/ /mnt/c/
Au passage, en fait je voulais plutôt dire ceci : # rm -R /mnt/c/* # cp -R /mnt/b/ /mnt/c/
Cette opération lit chaque fichier du disque source, crée le fichier correspondant sur le disque cible, et recommence.
Lire un fichier veut dire demander à l'OS de décoder les secteurs qui décrivent la structure du disque (correspondance entre nom de fichier et permissions, taille et position sur disque), puis de lire les secteurs correspondant aux données du fichier.
Écrire un fichier veut dire demander à l'OS d'allouer des secteurs encore inutilisés, et les enregistrer comme utilisés, associés à un nom.
Notons que cette commande ne copie pas les permissions des fichiers, mais des options de cp peuvent y remédier.
Oui, j'ai l'impression que c'est l'option -p qui le permet.
2) et un truc du genre # cat /dev/b > /dev/c
Cette opération copie tous les secteurs d'un disque à l'autre.
Globalement, si je comprends bien, pour peu que tous les conditions soient réunies (les deux disques sont physiquement identiques, /dev/c est démonté et aucune écriture sur /dev/b), après cette commande les deux disques sont totalement indiscernables.
Les différences sont nombreuses, et la lsite que je vais faire n'est pas du tout exhaustive :
[couic]
Merci beaucoup pour toutes ces explications très intéressantes. En fait, si je comprends bien, avec la commande (1) il y a tout une partie du disque /dev/b qui n'est pas copiée car pas accessible via le système de fichiers. Il faudrait un jour que je me penche sur la structure d'un disque dur et notamment sur toute la partie qu'on ne peut pas explorer avec un explorateur de fichiers justement...
Personnellement, je déconseille très fortement la copie de device à device d'un disque dur, ce n'est que très rarement une bonne idée.
Peut-être est-ce une bonne idée pour un clonage de disque, non ? Par exemple les logiciels de clonage ne font-ils pas au bout du compte ce type de copie ?
-- François Lafont
Le 16/07/2011 17:09, Nicolas George a écrit :
Les distributions prévoient en général un lien symbolique pour que le
lecteur optique apparaisse en tant que /dev/dvd quelle que soit la manière
dont il est connecté.
Ok. Je viens de constater que c'est bien le cas sur ma distribution.
1) un truc du genre
# cp -Rf /mnt/b/ /mnt/c/
Au passage, en fait je voulais plutôt dire ceci :
# rm -R /mnt/c/*
# cp -R /mnt/b/ /mnt/c/
Cette opération lit chaque fichier du disque source, crée le fichier
correspondant sur le disque cible, et recommence.
Lire un fichier veut dire demander à l'OS de décoder les secteurs qui
décrivent la structure du disque (correspondance entre nom de fichier et
permissions, taille et position sur disque), puis de lire les secteurs
correspondant aux données du fichier.
Écrire un fichier veut dire demander à l'OS d'allouer des secteurs encore
inutilisés, et les enregistrer comme utilisés, associés à un nom.
Notons que cette commande ne copie pas les permissions des fichiers, mais
des options de cp peuvent y remédier.
Oui, j'ai l'impression que c'est l'option -p qui le permet.
2) et un truc du genre
# cat /dev/b > /dev/c
Cette opération copie tous les secteurs d'un disque à l'autre.
Globalement, si je comprends bien, pour peu que tous les conditions
soient réunies (les deux disques sont physiquement identiques, /dev/c
est démonté et aucune écriture sur /dev/b), après cette commande les
deux disques sont totalement indiscernables.
Les différences sont nombreuses, et la lsite que je vais faire n'est pas du
tout exhaustive :
[couic]
Merci beaucoup pour toutes ces explications très intéressantes. En fait,
si je comprends bien, avec la commande (1) il y a tout une partie du
disque /dev/b qui n'est pas copiée car pas accessible via le système de
fichiers. Il faudrait un jour que je me penche sur la structure d'un
disque dur et notamment sur toute la partie qu'on ne peut pas explorer
avec un explorateur de fichiers justement...
Personnellement, je déconseille très fortement la copie de device à device
d'un disque dur, ce n'est que très rarement une bonne idée.
Peut-être est-ce une bonne idée pour un clonage de disque, non ? Par
exemple les logiciels de clonage ne font-ils pas au bout du compte ce
type de copie ?
Les distributions prévoient en général un lien symbolique pour que le lecteur optique apparaisse en tant que /dev/dvd quelle que soit la manière dont il est connecté.
Ok. Je viens de constater que c'est bien le cas sur ma distribution.
1) un truc du genre # cp -Rf /mnt/b/ /mnt/c/
Au passage, en fait je voulais plutôt dire ceci : # rm -R /mnt/c/* # cp -R /mnt/b/ /mnt/c/
Cette opération lit chaque fichier du disque source, crée le fichier correspondant sur le disque cible, et recommence.
Lire un fichier veut dire demander à l'OS de décoder les secteurs qui décrivent la structure du disque (correspondance entre nom de fichier et permissions, taille et position sur disque), puis de lire les secteurs correspondant aux données du fichier.
Écrire un fichier veut dire demander à l'OS d'allouer des secteurs encore inutilisés, et les enregistrer comme utilisés, associés à un nom.
Notons que cette commande ne copie pas les permissions des fichiers, mais des options de cp peuvent y remédier.
Oui, j'ai l'impression que c'est l'option -p qui le permet.
2) et un truc du genre # cat /dev/b > /dev/c
Cette opération copie tous les secteurs d'un disque à l'autre.
Globalement, si je comprends bien, pour peu que tous les conditions soient réunies (les deux disques sont physiquement identiques, /dev/c est démonté et aucune écriture sur /dev/b), après cette commande les deux disques sont totalement indiscernables.
Les différences sont nombreuses, et la lsite que je vais faire n'est pas du tout exhaustive :
[couic]
Merci beaucoup pour toutes ces explications très intéressantes. En fait, si je comprends bien, avec la commande (1) il y a tout une partie du disque /dev/b qui n'est pas copiée car pas accessible via le système de fichiers. Il faudrait un jour que je me penche sur la structure d'un disque dur et notamment sur toute la partie qu'on ne peut pas explorer avec un explorateur de fichiers justement...
Personnellement, je déconseille très fortement la copie de device à device d'un disque dur, ce n'est que très rarement une bonne idée.
Peut-être est-ce une bonne idée pour un clonage de disque, non ? Par exemple les logiciels de clonage ne font-ils pas au bout du compte ce type de copie ?
-- François Lafont
Francois Lafont
Le 16/07/2011 17:40, Sergio a écrit :
1) un truc du genre # cp -Rf /mnt/b/ /mnt/c/
2) et un truc du genre # cat /dev/b> /dev/c
?
Pour ça, la commande "dd" semble appropriée...
Je viens de voir la page man de cette commande ainsi que Wikipédia, apparemment :
Sauf qu'effectivement dd possède tout plein d'options qui ne me parlent guère mais qui doivent sûrement être utiles pour des copies de device à device.
-- François Lafont
Le 16/07/2011 17:40, Sergio a écrit :
1) un truc du genre
# cp -Rf /mnt/b/ /mnt/c/
2) et un truc du genre
# cat /dev/b> /dev/c
?
Pour ça, la commande "dd" semble appropriée...
Je viens de voir la page man de cette commande ainsi que Wikipédia,
apparemment :
Sauf qu'effectivement dd possède tout plein d'options qui ne me parlent
guère mais qui doivent sûrement être utiles pour des copies de device à
device.
Sauf qu'effectivement dd possède tout plein d'options qui ne me parlent guère mais qui doivent sûrement être utiles pour des copies de device à device.
-- François Lafont
Nicolas George
Francois Lafont , dans le message <4e21bb70$0$18127$, a écrit :
Au passage, en fait je voulais plutôt dire ceci : # rm -R /mnt/c/* # cp -R /mnt/b/ /mnt/c/
Oui, je m'en doutais et j'avais adapté en conséquence.
Oui, j'ai l'impression que c'est l'option -p qui le permet.
Il faut un peu plus pour les attributs étendus, les ACL, les hardlinks, les sparse files, etc.
Globalement, si je comprends bien, pour peu que tous les conditions soient réunies (les deux disques sont physiquement identiques, /dev/c est démonté et aucune écriture sur /dev/b), après cette commande les deux disques sont totalement indiscernables.
Oui. Enfin, il y a probablement des différences physiques, accessibles par SMART par exemple, mais c'est anecdotique.
Merci beaucoup pour toutes ces explications très intéressantes. En fait, si je comprends bien, avec la commande (1) il y a tout une partie du disque /dev/b qui n'est pas copiée car pas accessible via le système de fichiers. Il faudrait un jour que je me penche sur la structure d'un disque dur et notamment sur toute la partie qu'on ne peut pas explorer avec un explorateur de fichiers justement...
L'article de Wikipedia sur ext2 semble donner un bon point de départ.
Peut-être est-ce une bonne idée pour un clonage de disque, non ? Par exemple les logiciels de clonage ne font-ils pas au bout du compte ce type de copie ?
Bof. Pourquoi clôner un disque quand on peut par la même occasion nettoyer le système de fichiers des scories de l'âge ? Le seul intérêt que je voie, c'est de préserver les ctime, et les inconvénients sont multiples.
Francois Lafont , dans le message
<4e21bb70$0$18127$426a74cc@news.free.fr>, a écrit :
Au passage, en fait je voulais plutôt dire ceci :
# rm -R /mnt/c/*
# cp -R /mnt/b/ /mnt/c/
Oui, je m'en doutais et j'avais adapté en conséquence.
Oui, j'ai l'impression que c'est l'option -p qui le permet.
Il faut un peu plus pour les attributs étendus, les ACL, les hardlinks, les
sparse files, etc.
Globalement, si je comprends bien, pour peu que tous les conditions
soient réunies (les deux disques sont physiquement identiques, /dev/c
est démonté et aucune écriture sur /dev/b), après cette commande les
deux disques sont totalement indiscernables.
Oui. Enfin, il y a probablement des différences physiques, accessibles par
SMART par exemple, mais c'est anecdotique.
Merci beaucoup pour toutes ces explications très intéressantes. En fait,
si je comprends bien, avec la commande (1) il y a tout une partie du
disque /dev/b qui n'est pas copiée car pas accessible via le système de
fichiers. Il faudrait un jour que je me penche sur la structure d'un
disque dur et notamment sur toute la partie qu'on ne peut pas explorer
avec un explorateur de fichiers justement...
L'article de Wikipedia sur ext2 semble donner un bon point de départ.
Peut-être est-ce une bonne idée pour un clonage de disque, non ? Par
exemple les logiciels de clonage ne font-ils pas au bout du compte ce
type de copie ?
Bof. Pourquoi clôner un disque quand on peut par la même occasion nettoyer
le système de fichiers des scories de l'âge ? Le seul intérêt que je voie,
c'est de préserver les ctime, et les inconvénients sont multiples.
Francois Lafont , dans le message <4e21bb70$0$18127$, a écrit :
Au passage, en fait je voulais plutôt dire ceci : # rm -R /mnt/c/* # cp -R /mnt/b/ /mnt/c/
Oui, je m'en doutais et j'avais adapté en conséquence.
Oui, j'ai l'impression que c'est l'option -p qui le permet.
Il faut un peu plus pour les attributs étendus, les ACL, les hardlinks, les sparse files, etc.
Globalement, si je comprends bien, pour peu que tous les conditions soient réunies (les deux disques sont physiquement identiques, /dev/c est démonté et aucune écriture sur /dev/b), après cette commande les deux disques sont totalement indiscernables.
Oui. Enfin, il y a probablement des différences physiques, accessibles par SMART par exemple, mais c'est anecdotique.
Merci beaucoup pour toutes ces explications très intéressantes. En fait, si je comprends bien, avec la commande (1) il y a tout une partie du disque /dev/b qui n'est pas copiée car pas accessible via le système de fichiers. Il faudrait un jour que je me penche sur la structure d'un disque dur et notamment sur toute la partie qu'on ne peut pas explorer avec un explorateur de fichiers justement...
L'article de Wikipedia sur ext2 semble donner un bon point de départ.
Peut-être est-ce une bonne idée pour un clonage de disque, non ? Par exemple les logiciels de clonage ne font-ils pas au bout du compte ce type de copie ?
Bof. Pourquoi clôner un disque quand on peut par la même occasion nettoyer le système de fichiers des scories de l'âge ? Le seul intérêt que je voie, c'est de préserver les ctime, et les inconvénients sont multiples.
Nicolas George
Sergio , dans le message <4e21b0dd$0$20220$, a écrit :
Pour ça, la commande "dd" semble appropriée...
Tel quel, aucun intérêt, non. dd n'est utile que si on commence à lui passer des options subtiles pour la contrôler.
Sergio , dans le message <4e21b0dd$0$20220$426a74cc@news.free.fr>, a
écrit :
Pour ça, la commande "dd" semble appropriée...
Tel quel, aucun intérêt, non. dd n'est utile que si on commence à lui passer
des options subtiles pour la contrôler.
Sergio , dans le message <4e21b0dd$0$20220$, a écrit :
Pour ça, la commande "dd" semble appropriée...
Tel quel, aucun intérêt, non. dd n'est utile que si on commence à lui passer des options subtiles pour la contrôler.
Sergio
Le 16/07/2011 18:46, Nicolas George a écrit :
Sergio , dans le message<4e21b0dd$0$20220$, a écrit :
Pour ça, la commande "dd" semble appropriée...
Tel quel, aucun intérêt, non. dd n'est utile que si on commence à lui passer des options subtiles pour la contrôler.
C'est peut-être ce qu'il faut, justement, pour faire une copie disque à disque sans casser trop d'œufs ? (et assez rapidement en optimisant les buffers...).
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Le 16/07/2011 18:46, Nicolas George a écrit :
Sergio , dans le message<4e21b0dd$0$20220$426a74cc@news.free.fr>, a
écrit :
Pour ça, la commande "dd" semble appropriée...
Tel quel, aucun intérêt, non. dd n'est utile que si on commence à lui passer
des options subtiles pour la contrôler.
C'est peut-être ce qu'il faut, justement, pour faire une copie disque à disque sans casser trop d'œufs ? (et assez rapidement en
optimisant les buffers...).
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Sergio , dans le message<4e21b0dd$0$20220$, a écrit :
Pour ça, la commande "dd" semble appropriée...
Tel quel, aucun intérêt, non. dd n'est utile que si on commence à lui passer des options subtiles pour la contrôler.
C'est peut-être ce qu'il faut, justement, pour faire une copie disque à disque sans casser trop d'œufs ? (et assez rapidement en optimisant les buffers...).
-- Serge http://leserged.online.fr/ Mon blog: http://cahierdesergio.free.fr/ Soutenez le libre: http://www.framasoft.org
Francois Lafont
Le 16/07/2011 18:45, Nicolas George a écrit :
L'article de Wikipedia sur ext2 semble donner un bon point de départ.
Merci, je vais regarder ça.
Peut-être est-ce une bonne idée pour un clonage de disque, non ? Par exemple les logiciels de clonage ne font-ils pas au bout du compte ce type de copie ?
Bof. Pourquoi clôner un disque quand on peut par la même occasion nettoyer le système de fichiers des scories de l'âge ?
Mais le clonage ça peut être utile des fois quand on a 20 PC identiques à installer, non ? Les installations prennent du temps en général. Tu préconiserais d'autres méthodes ?
-- François Lafont
Le 16/07/2011 18:45, Nicolas George a écrit :
L'article de Wikipedia sur ext2 semble donner un bon point de départ.
Merci, je vais regarder ça.
Peut-être est-ce une bonne idée pour un clonage de disque, non ? Par
exemple les logiciels de clonage ne font-ils pas au bout du compte ce
type de copie ?
Bof. Pourquoi clôner un disque quand on peut par la même occasion nettoyer
le système de fichiers des scories de l'âge ?
Mais le clonage ça peut être utile des fois quand on a 20 PC identiques
à installer, non ? Les installations prennent du temps en général. Tu
préconiserais d'autres méthodes ?
L'article de Wikipedia sur ext2 semble donner un bon point de départ.
Merci, je vais regarder ça.
Peut-être est-ce une bonne idée pour un clonage de disque, non ? Par exemple les logiciels de clonage ne font-ils pas au bout du compte ce type de copie ?
Bof. Pourquoi clôner un disque quand on peut par la même occasion nettoyer le système de fichiers des scories de l'âge ?
Mais le clonage ça peut être utile des fois quand on a 20 PC identiques à installer, non ? Les installations prennent du temps en général. Tu préconiserais d'autres méthodes ?
