The pre-write check is safe and does not affect the write even if probing fails.
It merely warns and prompts for confirmation when detecting that the device
appears mounted, contains a partition table, or is an LVM physical volume.


If the user confirms, dd proceeds unaltered—the warning is dismissed;
if the user was mistaken, the prompt prevents accidental data loss.
Consequently, existing scripts and documented workflows (e.g., writing ISOs to 
USB drives)
are unaffected. 


The check provides a safety net against accidental data loss.


thanks,
Jianing Weng


On 09/09/2026 09:42, ii wrote:
>I have revised the patch substantially:


remove the file‑system structure overwrite check entirely.



remove  the libblkid dependency – the new implementation
does not pull in any extra library.


retain only a best-effort check that warns  the output block
device appears to be: currently mounted,  LVM physical volume,
or containing an MBR or GPT partition table




>These checks are performed by reading a few initial sectors directly
>and parsing the on‑disk signatures. The detection is purely advisory: 
>any failure during probing is silently ignored and treated as
>"nothing detected",  so dd will never fail or change its behaviour
>because of pre-write safety check. The warning is only issued when
>dd is run interactively, and it asks for user confirmation before 
proceeding.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
&gt;On 08/09/2026 15:11, Collin Funk<[email protected]&gt; wrote:
&gt;Wouldn't&nbsp;this&nbsp;change&nbsp;break&nbsp;common&nbsp;instructions&nbsp;people&nbsp;use&nbsp;to&nbsp;create
&gt;flash&nbsp;drives&nbsp;for&nbsp;installing&nbsp;GNU/Linux,&nbsp;or&nbsp;other&nbsp;operating&nbsp;systems?&nbsp;At
&gt;least,&nbsp;I&nbsp;remember&nbsp;'dd'&nbsp;commonly&nbsp;being&nbsp;recommended&nbsp;for&nbsp;that.&nbsp;Asking&nbsp;one
&gt;of&nbsp;the&nbsp;major&nbsp;slop&nbsp;bots:
&gt;
&gt;&nbsp; &nbsp;How&nbsp;do&nbsp;I&nbsp;write 
a&nbsp;Fedora&nbsp;ISO&nbsp;to&nbsp;a&nbsp;usb?
&gt;
&gt;Resulted&nbsp;in&nbsp;an&nbsp;answer&nbsp;involving&nbsp;the&nbsp;following&nbsp;steps:
&gt;
&gt;&nbsp; &nbsp; $&nbsp;sudo&nbsp;umount&nbsp;/dev/sda*&gt;
&gt;&nbsp; &nbsp; 
$&nbsp;sudo&nbsp;dd&nbsp;if=Fedora-Workstation.iso&nbsp;of=/dev/sda&nbsp;\
&gt;&nbsp; &nbsp; &nbsp; &nbsp;bs=4M&nbsp;status=progress&nbsp;oflag=sync
&gt;
&gt;If&nbsp;I&nbsp;understand&nbsp;correctly,&nbsp;the&nbsp;above&nbsp;steps&nbsp;would&nbsp;now&nbsp;give&nbsp;a&nbsp;warning&nbsp;with
&gt;this&nbsp;change&nbsp;if&nbsp;the&nbsp;drive&nbsp;has&nbsp;an&nbsp;MBR/GPT&nbsp;partition&nbsp;table,&nbsp;e.g.,&nbsp;if&nbsp;I
&gt;previously&nbsp;used&nbsp;the&nbsp;drive&nbsp;to&nbsp;install&nbsp;FreeBSD&nbsp;using&nbsp;a&nbsp;memstick&nbsp;image:
&gt;
&gt;&nbsp; &nbsp; $&nbsp;od&nbsp;-Ax&nbsp;-tx1&nbsp;-j 
510&nbsp;-N&nbsp;2&nbsp;FreeBSD-15.1-RELEASE-amd64-memstick.img
&gt;&nbsp; &nbsp; 0001fe&nbsp;55&nbsp;aa
&gt;&nbsp; &nbsp; 000200
&gt;&nbsp; 
$&nbsp;fdisk&nbsp;-l&nbsp;FreeBSD-15.1-RELEASE-amd64-memstick.img&nbsp;|&nbsp;tail&nbsp;-n&nbsp;3
&gt;&nbsp; 
Device&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Boot&nbsp;Start&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;End&nbsp;Sectors&nbsp;&nbsp;Size&nbsp;Id&nbsp;Type
&gt;&nbsp; 
FreeBSD-15.1-RELEASE-amd64-memstick.img1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1&nbsp;&nbsp;&nbsp;66584&nbsp;&nbsp;&nbsp;66584&nbsp;32.5M&nbsp;ef&nbsp;EFI&nbsp;(FAT-12/16/32)
&gt;&nbsp; 
&nbsp;FreeBSD-15.1-RELEASE-amd64-memstick.img2&nbsp;*&nbsp;&nbsp;&nbsp;&nbsp;66585&nbsp;3032424&nbsp;2965840&nbsp;&nbsp;1.4G&nbsp;a5&nbsp;FreeBSD
&gt;
&gt;While&nbsp;I&nbsp;am&nbsp;sympathetic&nbsp;to&nbsp;making&nbsp;things&nbsp;safer,&nbsp;I&nbsp;worry&nbsp;that&nbsp;this
&gt;behavior&nbsp;might 
come&nbsp;as&nbsp;welcome&nbsp;surprise&nbsp;to&nbsp;others.
&gt;
&gt;Collin
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
&gt; On 04/09/2026 22:54, 
Pádraig&nbsp;Brady&nbsp;<[email protected]&gt;&nbsp;wrote:
&gt;&nbsp;On&nbsp;04/09/2026&nbsp;10:22,&nbsp;ii&nbsp;via&nbsp;GNU&nbsp;coreutils&nbsp;Bug&nbsp;Reports&nbsp;wrote:
&gt;&gt;&nbsp;if&nbsp;dd&nbsp;is&nbsp;used&nbsp;to&nbsp;write&nbsp;block&nbsp;device,&nbsp;would&nbsp;destroy&nbsp;in-use&nbsp;devices,&nbsp;or&nbsp;LVM,&nbsp;&amp;nbsp;partition&nbsp;tables&nbsp;on&nbsp;devices.&nbsp;&amp;nbsp;
&gt;&gt;&nbsp;Before&nbsp;opening&nbsp;the&nbsp;output,&nbsp;probe&nbsp;with&nbsp;libblkid&nbsp;and&nbsp;warn&nbsp;if&nbsp;content&nbsp;is&nbsp;recognized,&nbsp;prompting&nbsp;for&nbsp;confirmation.
&gt;
&gt;&nbsp;Checking&nbsp;whether&nbsp;a&nbsp;device&nbsp;is&nbsp;mounted&nbsp;does&nbsp;seem&nbsp;potentially&nbsp;useful.
&gt;
&gt;&nbsp;Checking&nbsp;whether&nbsp;to&nbsp;overwrite&nbsp;existing&nbsp;file&nbsp;system&nbsp;structures&nbsp;seems&nbsp;less&nbsp;useful,
&gt;&nbsp;as&nbsp;that&nbsp;would&nbsp;be&nbsp;a&nbsp;very&nbsp;common&nbsp;scenario.&nbsp;&nbsp;Also&nbsp;that&nbsp;functionality&nbsp;adds&nbsp;the
&gt;&nbsp;libblkid&nbsp;dependency&nbsp;which&nbsp;isn't&nbsp;ideal.
&gt;
&gt;thanks,
&gt;Padraig






ii
[email protected]

Reply via email to