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. Fix: 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. How-To-Repeat: 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.
On 2013-02-24 15:31, root@ai1.alaska.net 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.
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open"