From owner-freebsd-current Mon Sep 23 14:53:53 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA24091 for current-outgoing; Mon, 23 Sep 1996 14:53:53 -0700 (PDT) Received: from eac.iafrica.com (196-7-192-103.iafrica.com [196.7.192.103]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA23796 for ; Mon, 23 Sep 1996 14:53:20 -0700 (PDT) Received: (from rnordier@localhost) by eac.iafrica.com (8.7.5/8.6.12) id XAA01258; Mon, 23 Sep 1996 23:52:12 +0200 (SAT) From: Robert Nordier Message-Id: <199609232152.XAA01258@eac.iafrica.com> Subject: Re: ncheck and a multi-lingual fsck To: jez@netcraft.co.uk (Jeremy Prior) Date: Mon, 23 Sep 1996 23:52:11 +0200 (SAT) Cc: freebsd-current@FreeBSD.org In-Reply-To: <199609231712.SAA10123@server.netcraft.co.uk> from Jeremy Prior at "Sep 23, 96 06:12:49 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Jeremy Prior wrote: > All, > I've always missed the lack of ncheck(8) in FreeBSD - The 4.4BSD > manual page for it is wrong - its functionality is not obsoleted by > fsck(8)! Specifically, I miss ncheck's `-s' option (find / -perm ... > is no substitute). > > My nostalgia turned into desperation when find started falling over > with an out-of-memory error in our news-spool partition during the > nightly /etc/security run. (Sorry, I don't have the error message to > hand - I can let people have it after tonight's run if they're > interested :-) > > I was about to write an ncheck clone (using fsck as a starting > point), and had even got to the point of soliciting sample output for > other vendor's versions, when I discovered that one already exists! > OpenBSD has had ncheck (actually ncheck_ffs) since mid August. > > So, I fetched, built, and installed their ncheck (no changes needed > other than the name :-), and it works fine! I'm currently in the process > of rewriting my /etc/security to use it. > > Anyway, I'm now wondering whether I should with it. My options are: > > 1. keep it to myself and shut up :-) > > 2. submit it as-is, and let someone else decide what to do with it; > (I could also submit chkdsk(8) - aka fsck_msdos at the same time...) > > or > > 3. go the whole way and submit it as part of a general `cleanup', where > each of the fs-dependent programs (fsck, ncheck, ...) are called by > an fs-independent parent (I'd use mount(8) as the template). > > What do other people think? Do people want this? Am I treading on > anyone else's toes? by doing this :-) Opinions? No opinion regarding most of this, but I'd be very wary of bringing across chkdsk/fsck_msdos. Although the FFS is far more complex, a fsck for the V*FAT fs actually has a more difficult task in some ways. (In an FFS context, a great many possible scenarios just "can't happen".) In the course of developing the vfatfs, I've had the opportunity to test all the recent versions of chkdsk, scandisk, fsck_* I could find. They _all_ have serious problems. Even MS scandisk for DOS 6.22 has major bugs, though it generally does a better job than other stuff. I've been working on a fsck_vfatfs myself, intermittently. I don't mind dropping this if something demonstrably better comes along, but -- for now -- I wouldn't let it, or anything else I've seen on UNIX near my DOS partitions. No point in inviting trouble unnecessarily.... -- Robert Nordier