Thank you for your prompt and thoughtful feedback


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. Probing failures are silently ignored—detection is 
purely advisory.
The check adds a safety net against accidental data loss without altering dd's 
core behaviour.


I hope this clarifies the intent. 


thanks,
Jianing Weng


On 08/09/2026 19:19, Padraig writes:
>Again I think the warning about existing structures will cause more issues than it solves.
>
>Also please keep all responses on the list.
>
>thanks,
>Padraig
>
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>On 07/09/2026 06:35, ii wrote:
> Dear Padraig,
> 
> 
Thank you for your prompt and thoughtful feedback on my initial patch.
> In particular, I appreciate the point that checking whether to overwrite
> existing file system structures is of limited utility , and that adding a
> dependency on libblkid is not ideal.
> 
> I have revised the patch substantially:
> 
>  1.
> 
>     remove the file‑system structure overwrite check entirely.
> 
>  2.
> 
>     remove the libblkid dependency – the new implementation
> 
>     does not pull in any extra library.
>  3.
>     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.
> 
> The patch is attached. Please let me know if you have further questions or suggestion.
> 
> Thank you again for your time and guidance,
> Jianing Weng
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 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