Re: proposed bsdlabel patch

On Tue, 30 Mar 2004, Ruslan Ermilov wrote:

> On Tue, Mar 30, 2004 at 11:06:41AM +0200, Hartmut Brandt wrote:
> > Not really. rm has no magic that interpretes da0 as /dev/da0. If you
> > happen to have a file da0 in your current directory (let's say the saved
> > disklabel or so) and specify just da0 to disklabel expecting that it
> > will work on /dev/da0 it will unexpecedly clobber your file. Such
> > automatisms make things not easier, but more complex - you have to
> > remember them. You need to get the habit to do ls -l before you do
> > disklabel da0. I'd say keep the '-f' option, that'll make things clearer.

I agree.  The conversions are hard to remember and different for almost
every utility that perpetrates them.  I never have problems with this
though.  Clobbering real disks is easy enough that I usually do much
more than ls to check that I'm writing to the disk that I want.

> FWIW, fdisk(8), diskinfo(8), fsck_ffs(8) (and probably others)
> prefer the file in the current directory to a /dev entry.

The misbehaviour of fsck_ffs is actually more complicated:

- In 4.4BSD (where fsck_ffs was plain fsck), fsck actually operated
  on the specified pathname.

- Merging NetBSD's fsck driver gave some or all of the following
  conversions:

--- The driver part (fsck) adds a /dev prefix if the specified pathname
    doesn't contain _any_ slashes, so ./foo works right, unlike for
    bsdlabel.

--- The fsck_ffs part starts by adding a /dev prefix under the same
    condition as fsck, so ./foo (almost) works right.

--- If fsck_fsck can't stat the file under its (possibly) converted
    pathname, then it (fsck_ffs) prints a message and continues with the
    specified pathname.  This causes various misbehaviours, e.g.,
    duplicate error messages.

Bruce