Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!ames!haven!adm!xadmx!postmaster@urbana.mcd.mot.com From: postmaster@urbana.mcd.mot.com Newsgroups: comp.unix.wizards Subject: mail to xenurus.gould.com Message-ID: <20207@adm.BRL.MIL> Date: 10 Jul 89 20:32:46 GMT Sender: news@adm.BRL.MIL Lines: 813 The enclosed mail message was addressed to a system which is no longer in service. We have attempted to forward your mail to the correct recipient(s). If this is not possible, you will recieve additional mail at the time of failure. In the future, please use the system name "urbana.mcd.mot.com" instead. Please correct any mailing lists or alias files that may reference any of the following obsolete system names: xenurus.gould.com fang.gould.com fang.urbana.gould.com vger.urbana.gould.com ccvaxa.gould.com ccvaxa.urbana.gould.com burt.urbana.gould.com mycroft.urbana.gould.com If you have any further problems or questions about mail to this site, please contact postmaster@urbana.mcd.mot.com. thank you for your cooperation, postmaster@urbana.mcd.mot.com Motorola Microcomputer Division, Urbana Design Center ---------- text of forwarded message: Received: from sem.brl.mil by placebo (5.61/1.34) id AA01830; Sat, 8 Jul 89 00:54:08 -0500 Received: by SEM.BRL.MIL id aj00393; 8 Jul 89 2:01 EDT Received: from SEM.BRL.MIL by SEM.brl.MIL id aa06686; 7 Jul 89 3:00 EDT Received: from sem.brl.mil by SEM.BRL.MIL id aa06644; 7 Jul 89 2:45 EDT Date: Fri, 07 Jul 89 02:45:24 EST From: The Moderator (Mike Muuss) To: UNIX-WIZARDS@BRL.MIL Reply-To: UNIX-WIZARDS@BRL.MIL Subject: UNIX-WIZARDS Digest V7#122 Message-Id: <8907070245.aa06644@SEM.BRL.MIL> UNIX-WIZARDS Digest Fri, 07 Jul 1989 V7#122 Today's Topics: Re: UUCP to Xenix site (long) STREAMS splstr() rsh fails with "accept: too many open files" chown (was: at files and permissions) Re: chown (was: at files and permissions) Re: Troff or pscat ? Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP local test Re: Do you know about C-Tree ? Re: at files and permissions Convert string time into seconds? Sun calctool Algorithm needed: reading/writing a large file Re: Information on `TUNEX' kernel tuning program Re: Should "ls -R" traverse symlinks? Re: Environment variables at login Re: Cartridge tape stuff Security ----------------------------------------------------------------- From: "Bruce A. Yanagida" Subject: Re: UUCP to Xenix site (long) Date: 5 Jul 89 19:15:56 GMT Keywords: UUCP, Xenix To: unix-wizards@sem.brl.mil Thanks to all who responded to my problem about connecting from a Berkeley UNIX site to a Xenix site. I have it working reliably now. Basically, my problem was that my UUCP defaults to even parity, while Xenix systems require zero parity. Therefore, all I needed to do was use P_ZERO in my L.sys line for the Xenix site. -- Bruce A. Yanagida (UUCP: ...!uw-beaver!sumax!ole!yanagida) Seattle Silicon Corporation 3075 112th Ave NE Bellevue, WA 98004 (206)-828-4422 ----------------------------- From: Erik Murrey Subject: STREAMS splstr() Date: 6 Jul 89 01:04:45 GMT To: unix-wizards@sem.brl.mil I see in streams.h for the 3b2 that splstr() is at spltty(). Does this mask out calls to timeout() routines? If not, then what is the appropriate level for a critical section of code that a timer routine modifies? I know this is RTFM, but I don't have the $200 set of device driver guides. E-mail, please. If anyone else wants to know, then mail me. Thanks! ... Erik -- Erik Murrey /| // /~~~~/ | / MPX Data Systems, Inc. / | / / /____/ |/ erik@mpx.com / / / / /| Data Systems, Inc. {vu-vlsi, bpa, cbmvax}!mpx1!erik / / / / |==================== ----------------------------- From: Edward Vielmetti Subject: rsh fails with "accept: too many open files" Date: 6 Jul 89 04:04:26 GMT Sender: usenet@math.lsa.umich.edu UUCP-Path: {mailrus,umix}!um-math!emv To: unix-wizards@sem.brl.mil rsh is dying on me with this error message. It appears to be a problem on the local end (in this case euterpe) because no matter where I rsh something the same error message. (Sun 3/160, SunOS 3.5, and yp master). /etc/pstat -T shows the 'inodes' at 226/226, so presumably that has something to do with it; I confess the rest of the output from pstat is rather uninformative to me. Other things seem to work fine, and I can telnet and ftp OK. euterpe% rsh urania echo foo accept: Too many open files --Ed ----------------------------- From: Chris Torek Subject: chown (was: at files and permissions) Date: 6 Jul 89 04:25:38 GMT To: unix-wizards@sem.brl.mil >In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >>... BSD allows only root to change file ownership. In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I certainly hope that V.4 doesn't have this *bogus* restriction. The restriction is not bogus, because the system supports disk quotas. If you could give away your own files, you could: mkdir .hide; chmod 700 .hide chdir .hide create_huge_file >foo chown prof1 foo create_huge_file >bar chown prof2 bar create_huge_file >baz chown prof3 baz All you need do is find someone with a high quota or no quota (such as a professor) who does not often check his own usage (such as a professor) and probably does not care that the disk is 99% full (such as a, er, well, never mind :-) ), and then give away files as necessary to keep under your own quota. You can regain ownership of the file by copying it to another disk partition, removing the original, and copying it back. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris ----------------------------- From: RAMontante Subject: Re: chown (was: at files and permissions) Date: 6 Jul 89 13:22:51 GMT To: unix-wizards@sem.brl.mil ->>... BSD allows only root to change file ownership. - ->I certainly hope that V.4 doesn't have this *bogus* restriction. - chris@mimsy.UUCP (Chris Torek) <18414@mimsy.UUCP> : -The restriction is not bogus, because the system supports disk quotas. - [ . . . ] -All you need do is find someone with a high quota or no quota (such -as a professor) who does not often check his own usage (such as a -professor) and probably does not care that the disk is 99% full (such There are also many potential problems from hostile users (generally undergraduates) --- consuming someone else's quota can break their running program, make them miss an assignment deadline, etc. Putting obscene or incriminating material in someone else's file system and then "turning them in" can do some real *major* damage. Hope I haven't inspired anyone with this...but hey, I prefer BSD anyway. ----------------------------- From: Peter da Silva Subject: Re: chown (was: at files and permissions) Date: 6 Jul 89 13:48:02 GMT To: unix-wizards@sem.brl.mil In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >... BSD allows only root to change file ownership. In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >I certainly hope that V.4 doesn't have this *bogus* restriction. In article <18414@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > The restriction is not bogus, because the system supports disk quotas. This assume that disk quotas are not bogus in a production environment. That is, outside a university... anyway, I'll rephrase my comment: I certainly hope that V.4 does not impose this bogus restriction if you choose to not make use of disk quotas. I also hope that V.4 doesn't enforce the other bogus restrictions I remember from my years at Berkeley. They didn't call it the "fascist file system" for nothing. [ Pardon my language, but I just saw Bill and Ted's Excellent Adventure ] -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "Bad K&R! Bad!" Personal: peter@sugar.hackercorp.com. `-_-' | -- C. Harald Koch Quote: Have you hugged your wolf today? 'U` | (chk@dciem.dnd.ca) ----------------------------- From: Doug Gwyn Subject: Re: chown (was: at files and permissions) Date: 6 Jul 89 21:13:19 GMT To: unix-wizards@sem.brl.mil In article <18414@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >>In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >>>... BSD allows only root to change file ownership. >In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >>I certainly hope that V.4 doesn't have this *bogus* restriction. >The restriction is not bogus, because the system supports disk quotas. So now the issue becomes: Is the BSD disk quota system bogus? Having had it break things I was doing, I hollered loudly enough that the system administrator who had decided to give me a finite quota changed it back to infinite. Not only does an enforced quota suffer from the same problems as the System V "ulimit", but messages generated by the system to the "appropriate" interactive terminal to warn you that you're approaching your quota can cause all sorts of damage, especially if your "terminal" is a communication channel, not a human-oriented device. (5620 DMD or 630 MTG users should recognize the problem.) There seem to me to be two valid services that can be performed by a disk "quota" system. One of them is to prevent runaway disk consumption such as cat x >> x and the other is to keep users from accumulating junk that fills the available disk. The first problem is dealt with adequately by a resource limit mechanism a la ulimit, or more reliably by a "dynamic" quota monitor attached to the specific session. The second problem can be dealt with administratively, with periodic use of "du|sort -rn" to find where the problems are. Realistic long-term storage quotas really have to be negotiated between the users and the system administrator anyway. These methods of providing disk quota services do not encounter the scenario that you described for the UID-based quota scheme when the file owner is allowed to chown his own file. Most of my use of "su" on our BSD-based systems is simply to chown files. That is indicative of a serious deficiency in normal user services on these systems. I would install a set-UID 0 "chown" (with appropriate checks) except for the hassle I'd get from the system admins around here. ----------------------------- From: Dick Dunn Subject: Re: Troff or pscat ? Date: 6 Jul 89 06:05:45 GMT To: unix-wizards@sem.brl.mil In article <2209@astroatc.UUCP>, ttl@astroatc.UUCP (Tony Laundrie) writes: [troff example input deleted; consider the PostScript output...] > 2281(a)S > 2330(test)S > 2436(of)S > 2508(the)S > 2604(emergenc)S <<< How can I prevent this type of word separation > 2839(y)S <<< from occuring? Is it troff or pscat that is > 2891(broadcast)S causing the problem? It's not a problem. Troff is positioning output as it believes it should. Pscat is gathering the output and turning it into PostScript as best it can. When pscat finds that after one character is output, the new position is the same as the explicit position of the next character, it combines the two characters and outputs them with a single call (ultimately in a single "show"). This collection goes on as long as the implicit motion from character widths matches the explicit positioning of characters. The savings in the size of the PostScript file from this straightforward opti- mization is enormous--note that the overhead per string is 8 bytes. It is almost fortuitous (?!) that the coalescing usually joins words back together--but this is by no means guaranteed. For various reasons, not all words get rejoined, nor should you expect them to be. If you're trying to find "words" in the pscat output, you're probably going at things in a very wrong way--what you're seeing is only character sequences which were caught by pscat's coalescing algorithm. (The same thing will happen with psroff = ditroff + psdit, although the circumstances are different.) In particular, any situation which causes troff to think the natural spacing of characters should be different from PostScript font widths will cause the splitting you see. Possible factors (speaking generally) include pair kerning, differing ideas of character widths in troff and the back end, and rounding errors in width calculations. If you need to find "words", look for them far upstream, in the input to troff. -- Dick Dunn rcd@ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870 ...Simpler is better. ----------------------------- From: Jos Vos Subject: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP Date: 6 Jul 89 06:28:41 GMT Keywords: UUCP TCP/IP uucpd uucico sockets BSD4.3 SysV.3 To: unix-wizards@sem.brl.mil Does anybody use the BSD4.3 uucpd daemon on System V.3 systems with some TCP/IP implementation with sockets (I use Wollongong's implementation) ? I want to use it for running UUCP (for upwards compatibility) over a wide-area company TCP/IP network, where remote login can't be done for security reasons. Please mail/post experiences with: - The porting problems (if any) with uucpd from BDS4.3. - The porting problems with AT&T's V.3 uucico (I know the TCP/IP socket support is in the code between BSD?? #ifdef's). - Any other problem I overlooked... Patches are of course appreciated :-) -- -- ###### Jos Vos ###### Internet jos@idca.tds.philips.nl ###### -- ###### ###### UUCP ...!mcvax!philapd!jos ###### ----------------------------- From: Hwajin Bae Subject: Re: Using the uucp daemon (TCP/IP) on System V.3 with TCP/IP Date: 6 Jul 89 18:28:19 GMT Keywords: UUCP TCP/IP uucpd uucico sockets BSD4.3 SysV.3 To: unix-wizards@sem.brl.mil In article <1126@ssp15.idca.tds.philips.nl> jos@idca.tds.PHILIPS.nl (Jos Vos) writes: >Please mail/post experiences with: >- The porting problems (if any) with uucpd from BDS4.3. >- The porting problems with AT&T's V.3 uucico (I know the TCP/IP socket > support is in the code between BSD?? #ifdef's). >- Any other problem I overlooked... HDB UUCP that comes with AT&T V.3.2 UNIX includes support for TLI, TLIS, and socket interfaces to TCP/IP connections. Using existing TLIS (TLI STREAMS Based) code, all you need is to set up listener service database to invoke uucico when a request comes in from a remote TCP/IP host. This is only useful if you have another machine with TCP/IP, TLI, and equivalent UUCP. Porting BSD 4.3 UUCP daemon has already been done several times for different incarnations of TCP/IP implementations for system V Unix's. Unfortunately none of them are "free" that I know of. -- Hwa-jin Bae hwajin@wrs.com ( a.k.a. {uunet,rtech,sun}!wrs!hwajin ) bae@tis.llnl.gov (Internet) 415/832-2926 Wind River Systems, 1351 Ocean Ave, Emeryville, CA 94608 415/428-2623 ----------------------------- From: system@bsu-ucs.uucp Subject: local test Date: 6 Jul 89 12:03:42 GMT To: unix-wizards@sem.brl.mil local test - I hope. ----------------------------- From: John Kjellman Subject: Re: Do you know about C-Tree ? Date: 6 Jul 89 15:35:55 GMT Expires: 20 Jul 89 05:00:00 GMT Keywords: c-tree, 1984 FairCom To: unix-wizards@sem.brl.mil To all who responded to my C-Tree question: (uccjcm@ecsvax.uncecs [John McLendon], jfh@rpp386.Cactus.ORD [John F. Haugh II], terryn@prcrs [Terry Neely], benah@adspp [Benjamin A. Hunsberger], larrydl@killer [Larry Clark], friedl@vsi [Steve J. Friedl], hwh@cup.portal.com [Hank Hankins], jeff@cdp [Jeff ?*], mgardi@watdcsu [Joe deSousa], mark@intek01 [Mark McWiggins], erlebach@utcsri [Beverly Erlebacher], bmadhyan@doctor [Bharat Madyani], limonce@pilot.njin.net [Tom Limoncelli], jb@aablue [John B Scalia]) THANKS A LOT, your efforts are much appreciated ! To summarize the responses: C-Tree is a B+ Tree file handling package. It has two levels of interfaces, the low-level B+ Tree stuff and the high level ISAM method (Indexed Sequential Access Method). Everyone that has used it loves it (it's fast, highly portable, and comes with source code for $395). Also available is an SQL interface, a report generator, and a programmers tool kit. See FairCom for details: FairCom Corporation 4006 W. Broadway Columbia Missouri 65203 Tel: (314)445-6833 FAX: (314)445-9698 KJohn P.S. Apparently I am the only person on the net that didn't know what C-Tree is...... P.P.S. #include /* I am in no way associated with FairCom * * Corp, just a nosy consultant :-) */ -- | Only /// | #include /*KJohn - The man without an Amiga*/ | | Amiga \XX/ | kjohn@richp1 or [ purdue | cs.ubc | mcdchg ] ! richp1 ! kjohn | ----------------------------- From: Peter da Silva Subject: Re: at files and permissions Date: 6 Jul 89 16:13:05 GMT To: unix-wizards@sem.brl.mil In article <8092@bsu-cs.bsu.edu>, dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: [no disk quotas in V.3] > I said: > ...BSD allows only root to change file ownership. > In article <4884@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > > I certainly hope that V.4 doesn't have this *bogus* restriction. > I doubt that it will need to. I hope you're right. But remember that V.4 is supposed to be V.3+BSD. Does anyone here really know what sort of crud V.4 (not V.3) is going to have in it? Streams *and* sockets, or so I hear... -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: peter@ficc.uu.net, +1 713 274 5180. | "Arrrrggggh! Personal: peter@sugar.hackercorp.com. `-_-' | Electronic mail sucks eggs." Quote: Have you hugged your wolf today? 'U` | -- eugene miya ----------------------------- From: Uri Blumenthal Subject: Re: at files and permissions Date: 6 Jul 89 16:17:56 GMT To: unix-wizards@sem.brl.mil From article <8072@bsu-cs.bsu.edu>, by dhesi@bsu-cs.bsu.edu (Rahul Dhesi): > > When you discuss a security problem that is specific to System V, > please be sure to say so clearly, else you may confuse naive users. First of all, not everybody familiar with System V, knows exactly which features of BSD (and what version!) it has or has not. So, for example, I didn't know that you can do "chown" only being root (and I consider it rather STUPID - System V solved this security hazard a lot nicer: it just clears all sticky bits!). Even wizards don't have to be familiar with all the flawors of UNIX (or tomorrow somebody will come up and say, like "but on my HP/UX it's different", or "on my A/UX", or whatever boo you can find today. Uri. ----------------------------- From: clewis@eci386.uucp Subject: Re: at files and permissions Date: 6 Jul 89 20:47:10 GMT To: unix-wizards@sem.brl.mil In article <8072@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: >In article <669@lzaz.ATT.COM> hutch@lzaz.ATT.COM (R.HUTCHISON) writes: >>If I wanted to be sneaky (and if "at" wasn't very smart), I could submit >>a "nasty" at job, go to the spool directory, and change the file's owner >>id to a target login and "at" would do the nasty to that login. >The above problem does not occur in BSD, because BSD allows only root >to change file ownership. 1) it isn't a problem in SV, 'cause at won't run it. Like he said. Because, even though you can chown a file away from yourself, at will insist that the setuid bits are set before believing the ownership of the file. And, when you chown, the setuid bits are turned *off*. And you can't turn 'em on once you've given the file away. 2) BSD *does* allow you to give files away. It turns off the setuid bits too. If it doesn't work on your system, obviously someone disabled it for accounting reasons. >When you discuss a security problem that is specific to System V, >please be sure to say so clearly, else you may confuse naive users. It wasn't necessary for him to say so, because it *isn't* a security problem. "at" needs setuid root permissions so that it can write in the cron/at spool directories. In SVR3, there's no specific utility to run the "at" jobs, they seem to be simply shovelled into cron. -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425 ----------------------------- From: Guy Harris Subject: Re: at files and permissions Date: 6 Jul 89 22:11:53 GMT To: unix-wizards@sem.brl.mil > I doubt that it will need to. Considering the BSD file system in S5R4 is intended to have support for disk quotas, then yes, it *will* need to permit you to disallow giving away files. It will probably be a configuration option. ----------------------------- From: Doug Toppin Subject: Convert string time into seconds? Date: 6 Jul 89 17:42:44 GMT Keywords: time To: unix-wizards@sem.brl.mil I have a user entered time/date in the format: yymmddhhmmss I need to convert this into seconds since the epoch and can't find a reference anywhere. If anyone knows how please let me know. I can't change the system time and then ask it what the time is in seconds. Doug Toppin uunet!melpar!toppin ----------------------------- From: Dominick Samperi Subject: Sun calctool Date: 6 Jul 89 18:16:22 GMT Keywords: calctool lost To: unix-wizards@sem.brl.mil Would somebody please send me a copy of the calctool posting that appeared recently in comp.sources.sun, or let me know where I can find a copy? I lost my copy due to a bad backup/restore. (I would have posted this to comp.sys.sun, but this site has trouble posting to moderated groups.) Thanks! -- Dominick Samperi -- ESCC samperi@marob.masa.com uunet!hombre!samperi ----------------------------- From: Jeffrey W Percival Subject: Algorithm needed: reading/writing a large file Date: 6 Jul 89 18:16:29 GMT To: unix-wizards@sem.brl.mil I am writing a C program (Ultrix, VAXstation 2000) to re-arrange a large disk file. The file contains a large number of fixed length records. My current method is this: read through the file, building 2 arrays in memory: array1 is an array of some attribute I want to sort on, and array2 is just array of ascending integers (record numbers in the first file). Then I sort array1, with array2 tracking the movements in array1. I end up with array2 being a mapping of record numbers between the input file and the sorted file. Finally, I loop through array2 doing a read on file1, record array2[i] and writing to file2, record i. Now, I'm not looking for help in the sorting of array1; my sorting algorithm is fast and efficient. What is taking a long time are the quasi-random seeks in file1 as file2 is sequentially built. I cannot have all of file1 in memory, but can have more than the one record I am currently using in this shuffle. How can I speed this up? -- Jeff Percival (jwp@larry.sal.wisc.edu) ----------------------------- From: Ken Burch Subject: Re: Information on `TUNEX' kernel tuning program Date: 6 Jul 89 18:59:38 GMT To: unix-wizards@sem.brl.mil In article <1144@vsi.COM> friedl@vsi.COM (Stephen J. Friedl) writes: } The latest IEEE Transactions on Software Engineering (Jul } 1989) has an article "TUNEX: A Knowledge-Based System for } Performance Tuning of the UNIX Operating Sysem" by Behrokh Samadi } from AT&T Bell Labs. [...] How would one go about getting a copy of this publication? -- Ken Burch 614-238-5852 | ntm1836@dsacg1.dla.mil DLA Systems Automation Center | or Columbus, OH | ...!osu-cis!dsacg1!ntm1836 ----------------------------- From: Doug Gwyn Subject: Re: Should "ls -R" traverse symlinks? Date: 6 Jul 89 21:23:57 GMT Keywords: symlink, find To: unix-wizards@sem.brl.mil In article <12377@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >There's no doubt that symlinks are useful, but it's discouraging >how many propagating difficulties they introduce. ... >However, for good reasons or ill, it seems that nearly every >program that calls stat(2) now wants to special-case ST_IFLNK. Yes -- as a case in point, the BRL UNIX System V emulation for 4.nBSD initially always traversed symlinks, because System V at the time didn't have symlinks and the simplest emulation was to treat them transparently. As I found problems applying the System V utilities with that behavior to actual instances of symlinks on our systems, I gradually added more and more special-casing, or in some cases options, to the utilities, just as you indicated. It's one of the things that led me to conclude that symlinks weren't sufficiently elegant to include in the "ultimate" operating system (whatever that may be). ----------------------------- From: Guy Harris Subject: Re: Environment variables at login Date: 6 Jul 89 22:25:57 GMT Keywords: environment login To: unix-wizards@sem.brl.mil >And now my question for the wizards: will the problem of setting up an >uniform process environment for any interactive and/or non-interactive >use be solved in a more elegant fashion in SysVR5 or in some BSD >version? S5R3.1 already has a mechanism to do that - you put entries of the form VARIABLE=value in "/etc/TIMEZONE" (a comment in the code says the name should be changed in S5R4; presumably the name indicates that it was intended to be used to set TZ, but it can set more than just TZ, so presumably the intent was to change the name to reflect that) and "init" sets up the environment of everything it spawns (except, apparently, for the single-user shell) with those values (max of 6 values, at least in S5R3.1). That's what the code seems to do, anyway; try it and see. ----------------------------- From: Chris Lewis Subject: Re: Cartridge tape stuff Date: 7 Jul 89 00:34:55 GMT To: unix-wizards@sem.brl.mil In article <757@mitisft.Convergent.COM> dold@mitisft.Convergent.COM (Clarence Dold) writes: >in article <1989Jun28.173209.1457@eci386.uucp>, clewis@eci386.uucp (Chris Lewis) says: >> tar and cpio do not change their formats regardless of the buffer size >> you give them, they simply use bigger I/O buffers. >One exception I can think of is EOT on a multi-volume archive. > cpio -ocvT512k >/dev/rmt0 >and EOT is reached somewhere in the midst of writing a 512K block, the next >reel will have a repeat of that 512K block. [And reads with small blocks would get out of sync] True. Didn't think of that. Mind you, most tar's don't support multi-volume (and frankly, I simply don't trust cpio multi-volume except *maybe* on floppies) so the question is moot for tar. >If a small buffer is used on the outbound side, and a large buffer is used >to read it, the opposite will happen, even on single reel archives. >An archive that is 33*512 byte, will come out to an uneven multiple of >512K, and the restore will fail, unable to read the last, apparently partial >set of blocks. H'm, I just tried this with cpio on ISC 1.0.6 and it worked just fine. try: cd /etc cpio -o > /tmp/foo passwd inittab group cd /tmp cpio -iC512000 < /tmp/foo (will say that 10000 blocks read, but will create the files just perfectly) (-C is an undocumented cpio argument on ISC, probably AT&T, Microport and Bell Tech. I belive they (whoever "they" were) replaced cpio with something called "ncpio" which appears to have been an internal enhanced version of cpio. This appears to be the only way to get arbitrarily sized buffers specified to cpio.) Even if true, on QIC devices you really do need big buffers to get any sort of reasonable throughput. So you should be able to choose a reasonable size. Any QIC driver that can't read/write more than 512 bytes at a time should be junked. Any 1/4" streamer that has variable length records wouldn't be able to read/write compatible QIC tapes anyhow. As a reasonable compromise: use 128K on QIC streamers - large enough to not have too bad a start-stop hit, not so large that you could run into severe problems on machines with small amounts of memory or lots of other users that are trying to get things done ;-). On 9-track, 5K is usually fine (tar limit), though there are some machines that can only handle 3K (some 3b's). Once you get above 5K blocks all bets are off as to whether the hardware can handle real physical blocks that big. There are a few machines that don't like > 32K or > 64K raw I/O because of DMA boundaries. 386 UNIX and NCR Towers have it right even though they have somewhat strange DMA structures. Some older PC UNIXes don't. For those machines, you might have to limit yourselves to 32K. Even then, you might be able to fake it: If your tar doesn't support buffers bigger than 5K, you can always pipe the output of tar thru dd: tar cvf - .... | dd bs= > /dev/.... [I may be mistaken, but doesn't 386 2.3.1 Xenix dd not support bs > 64K?] -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425 ----------------------------- From: Subject: Security Date: 7 Jul 89 03:01:45 GMT Keywords: UNIX, VAX/VMS Posted: Thu Jul 6 20:01:45 1989 To: unix-wizards@sem.brl.mil I will be bringing a new UUCP site on-line within the next 60 days. In preparation, I am trying to learn as much as possible about information system security. The main emphisis is on the UNIX and VAX/VMS operating systems. If you are aware of any mailing lists, publications, texts, or other sources of information on these subjects, please drop me a note. In an attempt to conserve bandwidth, as well as other obvious reasons, please Email me directly. Thank you for your assistence in this matter. - Steve ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." || - Jeremy S. Anderson #include cheetah@blake.acs.wahington.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ----------------------------- End of UNIX-WIZARDS Digest ************************** ---------- end of forwarded message