From owner-freebsd-bugs Tue Oct 16 1: 0: 8 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 5D99A37B40B for ; Tue, 16 Oct 2001 01:00:01 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f9G801s63466; Tue, 16 Oct 2001 01:00:01 -0700 (PDT) (envelope-from gnats) Date: Tue, 16 Oct 2001 01:00:01 -0700 (PDT) Message-Id: <200110160800.f9G801s63466@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: bin/31199: tunefs error is incorrect when enabling softupdates Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR bin/31199; it has been noted by GNATS. From: Bruce Evans To: Cc: Subject: Re: bin/31199: tunefs error is incorrect when enabling softupdates Date: Tue, 16 Oct 2001 17:56:30 +1000 (EST) On Mon, 15 Oct 2001, Crist J. Clark wrote: > On Tue, Oct 16, 2001 at 01:22:37AM +1000, Bruce Evans wrote: > > On Mon, 15 Oct 2001, Crist J. Clark wrote: > > [snip] More comments on [snip]: the problem is easy to fix in -current thanks to the changes in rev.1.14. All args are now parsed before committing to any changes, so pflag is known before getsb() and getsb() can open the device with the least access required. Either pass the open mode to getsb() or make pflag global. > > > The messages should reflect that it is collecting the values > > > before it actually tries to write them. Something more like, > > > > > > $ tunefs -n enable /dev/ad0s1a > > > tunefs: setting soft updates... > > > tunefs: cannot open /dev/ad0s1a: Permission denied > > > > The "setting" message used to be "soft updates set". I changed this to > > "soft updates changes from disabled to enabled" (and similarly for > > "soft updates cleared" so that the wording is similar for all the messages. > > OK. Probably better. This hasn't been committed yet, though? Right. It's hard to see in all my unrelated changes: Index: tunefs.c =================================================================== RCS file: /home/ncvs/src/sbin/tunefs/tunefs.c,v retrieving revision 1.20 diff -u -0 -r1.20 tunefs.c --- tunefs.c 30 Sep 2001 14:57:08 -0000 1.20 +++ tunefs.c 16 Oct 2001 07:30:46 -0000 @@ -297 +309,2 @@ - warnx("%s set", name); + warnx("%s changes from disabled to enabled", + name); @@ -304 +317,2 @@ - warnx("%s cleared", name); + warnx("%s changes from enabled to disabled", + name); > > > > And in a successful run (since tunefs(8) is already chatty on > > > success), > > > > > > $ tunefs -n enable /dev/ad0s1a > > > tunefs: setting soft updates... > > > tunefs: changes on /dev/ad0s1 done > > > > The "changes done" message is silly if tunefs has only printed "remains > > unchanged" messages. > > But then again, even if there are no changes, tunefs(8) > unconditionally writes the "modified" data. Yes. Perhaps it should be even more chatty and print: tunefs: updating superblock tunefs: changes on /dev/ad0s1 done [or error] Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message