Source-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: should newfs require a properly labeled partition by default? (was CVS commit: basesrc/sbin/newfs)



[ On Sunday, February 17, 2002 at 07:40:56 (-0800), Jason R Thorpe wrote: ]
> Subject: Re: CVS commit: basesrc/sbin/newfs
>
> On Sun, Feb 17, 2002 at 04:57:23PM +1100, Luke Mewburn wrote:
> 
>  > I'm curious as to who finds the old behaviour so useful and/or
>  > necessary that they can't first edit the disklabel to contain the
> 
> There are certain types of devices for which you might not want to use
> a disklabel.

While there are/were cases where the space occupied by a disklabel
is/was perhaps better usable for other purposes, the tradeoff seems
quite insignificant.  There are also cases where a disklabel seems to be
superfluous too, but even in those cases it does provide information
that can be useful (beyond simiply satisfying Luke's test -- eg. useful
for the human administrator, whether he/she knows it at the time or not).

>  > correct partition type and other information, or use newfs -F
>  > (which ignores the disk label entry entirely).
> 
> Then I suggest you fix -F to not require -s to also be provided unless
> the size of the device cannot be determined at run-time.

Yes, that would be a good fix too!  ;-)

>  > I received a reasonable amount of positive feedback about the addition
>  > of that test (which prevents non 4.2BSD file systems from being newfs-ed
>  > unless you use -F), and having been bitten myself by accidentally
>  > newfs-ing the wrong partition because of a one character typo (and I'm
>  > sure that I'm not the only one), I disagree strongly with your backing
>  > out of that test.
> 
> Yah, and I suppose we should make "rm -i" the default, too?

Jason I don't think these two are in any way related -- i.e. your
analogy is fatally flawed.  What you're saying is almost the same as
saying we should allow newfs to work on mounted filesystems too.
(obviously it should not, regardless of the securelevel, since doing so
will most certainly result in a loss of system integrity)

This is is an internal consistency check that's easy and obvious, and it
can (relatively) easily be overridden in the tiny fraction of cases
where/if it is truly "not desired".

-- 
                                                                Greg A. Woods

+1 416 218-0098;  <gwoods%acm.org@localhost>;  <g.a.woods%ieee.org@localhost>;  
<woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost>; VE3TCP; Secrets of the Weird 
<woods%weird.com@localhost>



Home | Main Index | Thread Index | Old Index