All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com>
Cc: Linux List Kernel Mailing <linux-kernel@vger.kernel.org>
Subject: Re: [question] What happens when dd writes data to a missing device?
Date: Sun, 11 Oct 2020 21:31:51 +0100	[thread overview]
Message-ID: <20201011203151.GD3576660@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CABXGCsOVXh89h2e4EuNbDKiCNwKm8599UE-h0GN-jPhpfyoCVA@mail.gmail.com>

On Mon, Oct 12, 2020 at 12:46:03AM +0500, Mikhail Gavrilov wrote:
> Hi folks!
> I have a question.
> What happens when dd writes data to a missing device?
> 
> For example:
> # dd if=/home/mikhail/Downloads/Fedora-Workstation-Live-x86_64-Rawhide-20201010.n.0.iso
> of=/dev/adb
> 
> Today I and wrongly entered /dev/adb instead of /dev/sdb,
> and what my surprise was when the data began to be written to the
> /dev/adb device without errors.
> 
> But my surprise was even greater when cat /dev/adb started to display
> the written data.
> 
> I have a question:
> Where the data was written

Into a file called "/dev/adb", of course.

> and could it damage the stored data in
> memory or on disk?

Why would it?  There's nothing magical about /dev - the same thing happened
as if you said
dd if=/home/mikhail/Downloads/whatever.iso of=/tmp/adb
or, for that matter, of=/home/mikhail/copy-of-that-damn-iso - it had been
asked to write into file with that name if it already existed or to create it
and write into it if it didn't exist...  So it had created a file in /dev
with name adb and stored a copy into it.  You might run out of space if the
file had been large enough, but that's about it...

Try ls -l /dev/adb /dev/sdb and compare these two - sdb will be something
like
brw-rw---- 1 root disk 8, 16 ....
and adb -
-rw-rw---- 1 root <some group> <size of that sucker> ...

Block device and regular file respectively...  man mknod if you are
curious about device nodes and creating them manually - usually that's
done by scripts called by udev when it discovers devices, but that's
what they boil down to in the end.

Again, there's nothing magical about /dev or the names of specific
device nodes created in it - it's just the usual place to put that
stuff into, but that's it; you could call mknod(2) to create such
device nodes in any directory, using any names.

  parent reply	other threads:[~2020-10-11 20:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-11 19:46 [question] What happens when dd writes data to a missing device? Mikhail Gavrilov
2020-10-11 19:52 ` Sven-Haegar Koch
2020-10-11 20:31 ` Al Viro [this message]
2020-10-12  1:57 ` Douglas Gilbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201011203151.GD3576660@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikhail.v.gavrilov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.