DD : comportement de conv=notrunc Le sujet est résolu

[dezix]

Bonjour,

Chacun devrait lire le manuel avant de poster !

=> J'ai lu

Extrait :

Code : Tout sélectionner

$ man dd
....
       notrunc
              ne pas tronquer le fichier de sortie
....

Mais voilà ça ne fait pas ce que j'attendais !


D'après ce que j'ai pu voir comme exemples,
cela signifie que si le fichier source if est plus petit que celui de sortie of
l'emploi de conv=notrunc permet de copier le contenu de if au début de of
en conservant le reste de of

Et par déduction si on ne met pas cette option,
le résultat devrait être la copie de if sur of

Or, j'ai testé le suivant :

Une clé USB :

Code : Tout sélectionner

Disque /dev/sdb : 14,9 GiB, 16008609792 octets, 31266816 secteurs
Modèle de disque : Cruzer Slice    
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x064a5b05

Périphérique Amorçage Début      Fin Secteurs Taille Id Type
/dev/sdb1              2048 31266815 31264768  14,9G  7 HPFS/NTFS/exFAT

qui contient quelques Mo de fichiers

Je fais la sauvegarde du MBR

Code : Tout sélectionner

# dd if=/dev/sdb of=mbr.img bs=512 count=1 conv=noerror,sync
1+0 enregistrements lus
1+0 enregistrements écrits
512 octets copiés, 0,00278143 s, 184 kB/s

1. Je restore le MBR avec conv=notrunc
pour ne pas perdre mes fichiers

Code : Tout sélectionner

# dd if=mbr.img of=/dev/sdb bs=512 conv=notrunc
1+0 enregistrements lus
1+0 enregistrements écrits
512 octets copiés, 0,00559218 s, 91,6 kB/s

=> Ok! je retrouve ma clé qui fonctionne et mes fichiers


2. Je refais sans conv=notrunc

Code : Tout sélectionner

# dd if=mbr.img of=/dev/sdb bs=512
1+0 enregistrements lus
1+0 enregistrements écrits
512 octets copiés, 0,00326331 s, 157 kB/s

Je pensais avoir une clé vide,
mais non, je retrouve tous mes fichiers.

Où est mon erreur ?

[dezix]

J'ai eu la réponse sur LQ :

C'est parce que /dev/sdb est un fichier de périphérique
et que les périphériques font exception -> ils ne sont pas troncables par définition.

Bien sur ce n'est pas dans le "Putain de Manuel"



J'aurais une question annexe :

Dans ce cas il serait assez intéressant
lorsque l'on souhaite créer une image d'un disque se terminant par pas mal d'espace vide,
de s'assurer/déplacer pour qu'il n'y ait plus rien que des zéros au delà d'un certain point,
et ne créer avec dd que l'image de la partie utilisée.

Comment cela peut-il se faire ?
(être certain qu'il n'y a pas de fragments de données fin de disque)

[dezix]

J'ai eu la réponse sur LQ :

C'est parce que /dev/sdb est un fichier de périphérique
et que les périphériques font exception -> ils ne sont pas troncables par définition.

J'ai eu une réponse complémentaire dont voici la traduction :

Ce n'est pas une exception, c'est comme ça que les choses fonctionnent.

Si vous écrivez un fichier (dans un système de fichiers), la taille sera déterminée en fonction des données que vous y écrivez.

dd , copy et beaucoup d'autres outils vont supprimer votre fichier original et en créer un nouveau (= écraser).

Mais si vous écrivez des données directement sur un périphérique physique,
vous ne pouvez pas supprimer/écraser des fichiers mais simplement écraser des blocs sur le périphérique.

Évidemment, les blocs non touchés ne seront pas affectés.

C'est votre propre décision [un utilisateur de base devrait en être conscient]

si vous utilisez dd sur un système de fichiers ou sur un périphérique - sans utiliser aucun système de fichiers.

Ceci dissipe le flou dans lequel j'étais quant à la nature des fichiers "périphériques de blocs"
car bien que sachant qu'ils représentent des périphériques matériels ou virtuels ( -> encore une notion pas hyper évidente)
je les considérais jusqu'à présent aussi comme des fichiers.

Pour cette raison, je m'attendais à un comportement de fichier,
car p.ex. /dev/sda est tout de même un fichier dans un système de fichiers.

Ne dit-on pas : " Sous Linux tout est fichier "


Je pense avoir éclairci ce point pour moi,
j'espère que cela le soit aussi pour vous qui m'avez lu.

[PascalHambourg]

Dans ce cas il serait assez intéressant
lorsque l'on souhaite créer une image d'un disque se terminant par pas mal d'espace vide,
de s'assurer/déplacer pour qu'il n'y ait plus rien que des zéros au delà d'un certain point,
et ne créer avec dd que l'image de la partie utilisée.

Pas pratique. Notamment si le disque a une table de partition au format GPT, une copie de sauvegarde est faite à la toute fin du disque.
Par contre tu peux créer un fichier image "creux" avec l'option "sparse" de dd ou cp pour ne pas enregistrer les longues séquences de zéros. La taille réelle d'un fichier creux est inférieure à sa taille apparente. Mais il faut que le système de fichiers de destination supporte les fichiers creux, ce qui est bien sûr le cas des systèmes de fichiers standard de Linux comme ext4.

dd , copy et beaucoup d'autres outils vont supprimer votre fichier original et en créer un nouveau (= écraser).

Non, le fichier n'est pas supprimé et recréé. Seul son contenu est écrasé. Tu peux le vérifier en affichant le numéro d'inode du fichier avant et après l'opération avec "ls -i" ou stat, il ne change pas.

[dezix]

@PascalHambourg

Merci et bon WE