Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3661758pxu; Sun, 11 Oct 2020 19:15:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwvn4aj9lsHJPgWqdPiOWvqOo6g1cU4P6EAlpoZ6+kGoI98fbCOrT/nXcZ+OcslBFtBflwO X-Received: by 2002:a05:6402:207c:: with SMTP id bd28mr11492061edb.316.1602468909238; Sun, 11 Oct 2020 19:15:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602468909; cv=none; d=google.com; s=arc-20160816; b=Jj1ANZwNuTeiwfk3IgHrUleYWQ8+rkDjw0znp3zCMXLuah2jFMeAwA46e8mXyUqGn2 FoG5xNRF0m8P4UjkEcerOmHk1nrq461ccqFSFYeM70K2U2pNlOopRREI80l+/y+X5Joa +LpoC7niDACJvLxK8mdrXp46QzMzveKEbi2xncCEEbxISaW7y/F1FCldH/Q/LaPAH5Mk yTEUxhe/CAOIJh4w5dq9otwwhV0N0KmnmwgGbAk1qGziT5ng532mCfatidKxyNn3JXT7 A3pLtJowsb2PeOkkAR0GD9JJTEINdPBeswRVc/XR9hq2TTRFOtjHAUQrkZdE7fsK891H hsfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date; bh=VtuDieFwLwMuV5ntSCVqK52mtkmoj1IYEUKl2zJGEs4=; b=vGJVW6oM2q2b1BIh1dUPW3tsJln8qfwt0wOfLy5wrdPHIu0jSY5cNt7LF3B+r7AORl QToMDnZvv6J6i8S5kzZitqfG/8ROkSl55nwjyICGdEEHNcmMq2SrsQj27BkL3OoTgTpp 9XuUEU3N1rD05UND59AW3VDnDMd6IBrfAtaY+GN48w1vUEUaMmfW4l4xLMtvcpw5fgbY NdlY4USrdY2gJJuQvbjU9J+g5R62P+ajiqwrskdPirlIjySjlIe3SnALqWx4xKCJtj+G vtLx7QSvYePAExmh2Ei+ie3YisER1PMFgowtatm9qA+F1CQhvucF/b8X7Cx6x0eYyTJq SrqQ== 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 dk23si12966379edb.193.2020.10.11.19.14.47; Sun, 11 Oct 2020 19:15:09 -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 S1727027AbgJKUA6 (ORCPT + 99 others); Sun, 11 Oct 2020 16:00:58 -0400 Received: from hydra.sdinet.de ([136.243.3.21]:43646 "EHLO mail.sdinet.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726335AbgJKUA5 (ORCPT ); Sun, 11 Oct 2020 16:00:57 -0400 X-Greylist: delayed 514 seconds by postgrey-1.27 at vger.kernel.org; Sun, 11 Oct 2020 16:00:57 EDT Received: from aurora.sdinet.de (aurora.sdinet.de [193.103.159.39]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: haegar) by mail.sdinet.de (bofa-smtpd) with ESMTPSA id 9C3DE34028F; Sun, 11 Oct 2020 21:52:21 +0200 (CEST) Date: Sun, 11 Oct 2020 21:52:20 +0200 (CEST) From: Sven-Haegar Koch To: Mikhail Gavrilov cc: Linux List Kernel Mailing Subject: Re: [question] What happens when dd writes data to a missing device? In-Reply-To: Message-ID: References: User-Agent: Alpine 2.23 (DEB 453 2020-06-18) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 12 Oct 2020, Mikhail Gavrilov wrote: > 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 and could it damage the stored data in > memory or on disk? If the device node /dev/adb does not exist (most likely udev case when you don't have the device/no module loaded for it) then dd as root will just create a normal file inside the /dev ramdisk. Only if the device node exists but is not handled then something else like an open error will happen. c'ya sven-haegar -- Three may keep a secret, if two of them are dead. - Ben F.