LinuxQuestions.org - [SOLVED] dd : Basic behaviour not what expected

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - dd : Basic behaviour not what expected (https://www.linuxquestions.org/questions/linux-newbie-8/dd-basic-behaviour-not-what-expected-4175655310/)

dd : Basic behaviour not what expected

I know the Learn the DD command page here in LQ
and
I have read the FM ;-)

But I can't understand something very basic with DD

Let me show an example :

Here an USB stick with a dos parts table, 1 NFS part with some Files written onto

Code:

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

Now I dd the first 512 B to create a backup image of the MBR

Code:

# 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

After I use the following command :

Code:

# 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

According to my understanding of the dd FM
I would have an empty pen drive with the same NTFS part,
but the files are still here.

Normaly I should use :

Code:

# dd if=mbr.img of=/dev/sdb bs=512 conv=notrunc

to get this result.

So, please someone might tell me where I'm wrong ?

Thanks.

If that matters I'm running Bash on Debian Testing

Code:



$ uname -sro

Linux 4.19.0-5-amd64 GNU/Linux





$ bash --version

GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)

Copyright (C) 2019 Free Software Foundation, Inc.

Licence GPLv3+ : GNU GPL version 3 ou ultérieure <http://gnu.org/licenses/gpl.html>





$ dd --version

dd (coreutils) 8.30

Copyright © 2018 Free Software Foundation, Inc.

License GPLv3+ : GNU GPL version 3 ou ultérieure <https://www.gnu.org/licenses/gpl.fr.html>

Ceci est un logiciel libre. Vous êtes libre de le modifier et de le redistribuer.

Ce logiciel n'est accompagné d'ABSOLUMENT AUCUNE GARANTIE, dans les limites

permises par la loi.

Écrit par Paul Rubin, David MacKenzie et Stuart Kemp.

All you have done is copy one sector, then write the same data back. Why would you think that would affect your files (or the filesystem) that exist elsewhere on the disk ?. The partition table merely defines the start and length of each partition - nothing more.

Quote:

Originally Posted by dezix (Post 6003016)

After I use the following command :

Code:

# 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

According to my understanding of the dd FM
I would have an empty pen drive with the same NTFS part,
but the files are still here.

Quote:

Normaly I should use :

Code:

# dd if=mbr.img of=/dev/sdb bs=512 conv=notrunc

to get this result.

I think I understand your reasoning now. If /dev/sdb were a regular file, it would be truncated. But it is a device file, which can't be truncated.

The files are still there because you haven't altered the part of the disk they are on. You've only rewritten the MBR. And since the new MBR is identical to the old one, the partition table inside it will still allow the kernel to find out where the first partition starts and so find the files.

Also, according to https://stackoverflow.com/questions/...a-disk-with-dd, the notrunc option doesn't affect device files.

Quote:

Originally Posted by berndbausch (Post 6003021)

After this dd command, the first 512 bytes of the disk have exactly the same content as before the command. In other words, the disk's content hasn't changed. Why do you expect that your files disappear?

I think I understand your reasoning now. If /dev/sdb were a regular file, it would be truncated. But it is a device file, which can't be truncated.

OK! I understand that.

But there is no mention of such behaviour in the FM :(

Is there other kinds of exception that basic user should be aware ?

this is not an exception, this is how things work.
If you write a file (in a filesystem) the size will be determined based on the data you write into it. dd, copy and a lot of other tools will remove your original file and create a new one (= overwrite).
But if you write data directly onto a physical device you cannot remove/overwrite files but simply overwrite blocks on the device. Obviously non-touched blocks will not be affected.

It is your own decision [a basic user should be aware of] if you dd into a file on a filesystem or on a device - without using any filesystem.