standards/176412: newfs writes by default, compare to bsdlabel/disklabel.

Giorgos Keramidas keramida at
Mon Mar 4 14:50:01 UTC 2013

The following reply was made to PR standards/176412; it has been noted by GNATS.

From: Giorgos Keramidas <keramida at>
To: root at
Cc: FreeBSD-gnats-submit at
Subject: Re: standards/176412: newfs writes by default, compare to
Date: Mon, 4 Mar 2013 15:47:34 +0100

 On 2013-02-24 15:31, root at wrote:
 > >Number:         176412
 > >Category:       standards
 > >Synopsis:       newfs writes by default, compare to bsdlabel/disklabel.
 > fdisk/bsdlabel will not write to a drive by default, and require
 > special options to do so, yet newfs will destroy an entire drive,
 > easily and accidently, unlike other dangerous utilities.  This can
 > cause severe problems when a user only wants newfs to read and report
 > superblocks, and in utilizing the command, may easily forget the -N
 > option, whereafter, the user loses his entire drive and all data.  It
 > is also easy to be careless with newfs when previously, fdisk/bsdlabel
 > are used without worry of accidental destructive writes to a drive.
 > Play with newfs to read superblocks on a drive, and while
 > experimenting with options, forget the -N option one time, and your
 > drive and data are lost forever.
 > It would be consistent with dangerous utilities like fdisk/bsdlabel
 > for newfs to read by default, and only write when a user clearly
 > demands such functionality.  There is no good reason for newfs to
 > operate otherwise.  It's an accident waiting to happen, almost as if
 > deliberately.
 newfs is not the only utility that can 'write by default' on a raw disk,
 possibly overwriting important data.  dd(1), cat(1) and pretty much any
 other tool that can be pointed at a disk can do the same.  For instance
 it's always possible to write the wrong disk number in commands like:
     dd bs=4m if=imagefile.bin of=/dev/ada1
     ssh remotehost 'cat imagefile.bin' | tee /dev/ada0
 The -N option is fine in newfs as an equivalent of --dry-run in other
 tools, but I don't think it makes sense to break compatibility with
 almost 40 years of history just because it can be unsafe if misused.

More information about the freebsd-standards mailing list