Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3662480pxu; Sun, 11 Oct 2020 19:17:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwtgdh59SYEWXKYE3PJR7pXQSVVloqh4e78+ay4a+QkxjN+05ylFboGLTaqqyHp6TIinf7u X-Received: by 2002:aa7:dcc7:: with SMTP id w7mr11920333edu.80.1602469027246; Sun, 11 Oct 2020 19:17:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602469027; cv=none; d=google.com; s=arc-20160816; b=x7J3fIhlbOQRHFb9nAiN/waYYITTwWPZGovrRfp0DoN+Uqu6DKxYmL7vDSzapNyhi8 lQq8MNd8rs8xe/G3di04pIZQb6cCgZYUa/oio9zSp3ekBHZ6TTvVRR/wGOxUSqqXYnDe PfmQvkjYry1lvUjHY1XRtAXvJoRvygIaIQZKDpf6SIVbYmIFHL0NLDFanuN1Q/Q2eXPN 6q60KOQwqn69yqgE0/zymv0F5efyAcyhaNQsKzKBYog10BF4pKFoLbKNlQQiI/Bo37Sq Wxeuzy4u42ZGF7GkFOWmettKcAMqHbkUL4/SDEOS8nKAqKXVamsjZtmBykC9Rlu/mNZr IAtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=o+68NdO6AQaGkQyAYh+fsWs8yAWdpEEaAo0g/ttIszg=; b=o1LGHgQIioBHaY90LoDrCFd3vmrpui0JkM0m/+/hGMcM0q8fV/qu9DiuUQ3ZTv/+E/ R7nPvTDHvAZaMWO/oFkP8PRrAgs262MsCdrcvr2vVMAX7Os7pfTFXYAJgvY9hQC2SfdM Dcc7kOvbPTcBlEx1oB+2JJgRs7kTDyNY9LcgJdNFbOiSONs6FrF8NK5Se4NOysjgwYdi q5y3615u6D4CFCFc6lg829iBli/9X28GHfYDsF/Q4ppVQzXUjMNZGwii08VSsT6//WoI 9wsoln3ZUBrVCOTLDlEp7PVfgedUbxvk87yBv2XDJUqnaY4pnQ8U4HFTtL2mThYWpcNn ZqLg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t21si11253237edy.511.2020.10.11.19.16.44; Sun, 11 Oct 2020 19:17:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729412AbgJKUcA (ORCPT + 99 others); Sun, 11 Oct 2020 16:32:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42208 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726507AbgJKUb7 (ORCPT ); Sun, 11 Oct 2020 16:31:59 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6A6A4C0613CE for ; Sun, 11 Oct 2020 13:31:59 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kRi0V-00FaRp-PU; Sun, 11 Oct 2020 20:31:51 +0000 Date: Sun, 11 Oct 2020 21:31:51 +0100 From: Al Viro To: Mikhail Gavrilov Cc: Linux List Kernel Mailing Subject: Re: [question] What happens when dd writes data to a missing device? Message-ID: <20201011203151.GD3576660@ZenIV.linux.org.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 ... 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.