From owner-freebsd-isp Tue Jun 17 10:21:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA24221 for isp-outgoing; Tue, 17 Jun 1997 10:21:16 -0700 (PDT) Received: from rainey.blueneptune.com (root@rainey.blueneptune.com [207.104.147.225]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA24216 for ; Tue, 17 Jun 1997 10:21:12 -0700 (PDT) From: michael@blueneptune.com Received: (from michael@localhost) by rainey.blueneptune.com (8.6.12/8.6.12) id KAA19182 for isp@freebsd.org; Tue, 17 Jun 1997 10:21:24 -0700 Message-Id: <199706171721.KAA19182@rainey.blueneptune.com> Subject: Re: tar hangs 2.2.x system To: isp@freebsd.org Date: Tue, 17 Jun 1997 10:21:24 -0700 (PDT) In-Reply-To: <3.0.32.19970617110435.00afb750@etinc.com> from "dennis" at Jun 17, 97 11:04:38 am Reply-To: michael@blueneptune.com X-Mailer: ELM [version 2.4 PL24 ME8b] Content-Type: text Sender: owner-isp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>> tar -cvf /dev/rfd0 somefiles >>>> >>>> Note the "raw" device. >> >> Buffered devices (/dev/fd0) are JUST and ONLY for mounting >> something (and for swapon(8)). >> >> Raw devices (/dev/rfd0) are FOR EVERYTHING ELSE. >> >>Sorry for shouting, but from some non-newbie like dennis, i would have >>expected to know this. I'm repeating this over and over again to my >>clients on any Unix course i'm teaching. > > Perhaps true, but in the commercial world you cant instantaneously > change all of your documents and procedures to fix something that > has worked since the beginning of time. They both SHOULD work, and > changing a basic procedure is quite painful. Maybe I'm a special case, but in the 15+ years I've been working with Unix, I've -always- known to use the raw device for tape archives. And most system documentation I've looked at indicates that this is the case. I would never even try to use a buffered device for tar, and I wouldn't be surprised in any case where it didn't work the same as a raw device. Even if it did work on systems where you've been using it, I have a hard time buying the argument that something that has always worked should be maintained as working in the same fashion. If it's documented to work in a specific way, sure, I buy it then. But if it's an undocumented behaviour, and general knowledge for many years indicates that you shouldn't do it, then I think it's a bad practice to expect that behaviour to remain. On the flip side, it should not arbitrarily be removed, either, for pretty much the same reasons you state. But if a design change happens to make that undocumented feature break, then in general I think that's ok. [Sorta like "lseek(fd, 0, 0)" with no prototype in scope. It's neither wise nor recommended, but it works on nearly all flavors of Unix... until off_t is increased to 64 bits.] -- Michael Bryan michael@blueneptune.com