mail to xenurus.gould.com
postmaster at urbana.mcd.mot.com
postmaster at urbana.mcd.mot.com
Tue Jul 11 06:32:46 AEST 1989
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 at urbana.mcd.mot.com.
thank you for your cooperation,
postmaster at 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) <Unix-Wizards-Request at BRL.MIL>
To: UNIX-WIZARDS at BRL.MIL
Reply-To: UNIX-WIZARDS at BRL.MIL
Subject: UNIX-WIZARDS Digest V7#122
Message-Id: <8907070245.aa06644 at 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" <yanagida at ole.uucp>
Subject: Re: UUCP to Xenix site (long)
Date: 5 Jul 89 19:15:56 GMT
Keywords: UUCP, Xenix
To: unix-wizards at 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 <erik at mpx2.mpx.com>
Subject: STREAMS splstr()
Date: 6 Jul 89 01:04:45 GMT
To: unix-wizards at 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 at mpx.com / / / / /| Data Systems, Inc.
{vu-vlsi, bpa, cbmvax}!mpx1!erik / / / / |====================
-----------------------------
From: Edward Vielmetti <emv at math.lsa.umich.edu>
Subject: rsh fails with "accept: too many open files"
Date: 6 Jul 89 04:04:26 GMT
Sender: usenet at math.lsa.umich.edu
UUCP-Path: {mailrus,umix}!um-math!emv
To: unix-wizards at 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 <chris at mimsy.uucp>
Subject: chown (was: at files and permissions)
Date: 6 Jul 89 04:25:38 GMT
To: unix-wizards at sem.brl.mil
>In article <8072 at bsu-cs.bsu.edu> dhesi at bsu-cs.bsu.edu (Rahul Dhesi) writes:
>>... BSD allows only root to change file ownership.
In article <4884 at ficc.uu.net> peter at 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 at mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: RAMontante <bobmon at iuvax.cs.indiana.edu>
Subject: Re: chown (was: at files and permissions)
Date: 6 Jul 89 13:22:51 GMT
To: unix-wizards at sem.brl.mil
->>... BSD allows only root to change file ownership.
-
->I certainly hope that V.4 doesn't have this *bogus* restriction.
-
chris at mimsy.UUCP (Chris Torek) <18414 at 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 <peter at ficc.uu.net>
Subject: Re: chown (was: at files and permissions)
Date: 6 Jul 89 13:48:02 GMT
To: unix-wizards at sem.brl.mil
In article <8072 at bsu-cs.bsu.edu> dhesi at bsu-cs.bsu.edu (Rahul Dhesi) writes:
>... BSD allows only root to change file ownership.
In article <4884 at ficc.uu.net> peter at ficc.uu.net (Peter da Silva) writes:
>I certainly hope that V.4 doesn't have this *bogus* restriction.
In article <18414 at mimsy.UUCP>, chris at 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 at ficc.uu.net, +1 713 274 5180. | "Bad K&R! Bad!"
Personal: peter at sugar.hackercorp.com. `-_-' | -- C. Harald Koch
Quote: Have you hugged your wolf today? 'U` | (chk at dciem.dnd.ca)
-----------------------------
From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: chown (was: at files and permissions)
Date: 6 Jul 89 21:13:19 GMT
To: unix-wizards at sem.brl.mil
In article <18414 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>>In article <8072 at bsu-cs.bsu.edu> dhesi at bsu-cs.bsu.edu (Rahul Dhesi) writes:
>>>... BSD allows only root to change file ownership.
>In article <4884 at ficc.uu.net> peter at 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 <rcd at ico.isc.com>
Subject: Re: Troff or pscat ?
Date: 6 Jul 89 06:05:45 GMT
To: unix-wizards at sem.brl.mil
In article <2209 at astroatc.UUCP>, ttl at 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 at ico.isc.com uucp: {ncar,nbires}!ico!rcd (303)449-2870
...Simpler is better.
-----------------------------
From: Jos Vos <jos at idca.tds.philips.nl>
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 at 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 at idca.tds.philips.nl ######
-- ###### ###### UUCP ...!mcvax!philapd!jos ######
-----------------------------
From: Hwajin Bae <hwajin at wrswrs.wrs.com>
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 at sem.brl.mil
In article <1126 at ssp15.idca.tds.philips.nl> jos at 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 at wrs.com ( a.k.a. {uunet,rtech,sun}!wrs!hwajin )
bae at tis.llnl.gov (Internet) 415/832-2926
Wind River Systems, 1351 Ocean Ave, Emeryville, CA 94608 415/428-2623
-----------------------------
From: system at bsu-ucs.uucp
Subject: local test
Date: 6 Jul 89 12:03:42 GMT
To: unix-wizards at sem.brl.mil
local test - I hope.
-----------------------------
From: John Kjellman <kjohn at richsun.uucp>
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 at sem.brl.mil
To all who responded to my C-Tree question:
(uccjcm at ecsvax.uncecs [John McLendon],
jfh at rpp386.Cactus.ORD [John F. Haugh II],
terryn at prcrs [Terry Neely],
benah at adspp [Benjamin A. Hunsberger],
larrydl at killer [Larry Clark],
friedl at vsi [Steve J. Friedl],
hwh at cup.portal.com [Hank Hankins],
jeff at cdp [Jeff ?*],
mgardi at watdcsu [Joe deSousa],
mark at intek01 [Mark McWiggins],
erlebach at utcsri [Beverly Erlebacher],
bmadhyan at doctor [Bharat Madyani],
limonce at pilot.njin.net [Tom Limoncelli],
jb at 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 <std_disclaimer> /* I am in no way associated with FairCom *
* Corp, just a nosy consultant :-) */
--
| Only /// | #include <std/disclaimer> /*KJohn - The man without an Amiga*/ |
| Amiga \XX/ | kjohn at richp1 or [ purdue | cs.ubc | mcdchg ] ! richp1 ! kjohn |
-----------------------------
From: Peter da Silva <peter at ficc.uu.net>
Subject: Re: at files and permissions
Date: 6 Jul 89 16:13:05 GMT
To: unix-wizards at sem.brl.mil
In article <8092 at bsu-cs.bsu.edu>, dhesi at 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 at ficc.uu.net> peter at 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 at ficc.uu.net, +1 713 274 5180. | "Arrrrggggh!
Personal: peter at sugar.hackercorp.com. `-_-' | Electronic mail sucks eggs."
Quote: Have you hugged your wolf today? 'U` | -- eugene miya
-----------------------------
From: Uri Blumenthal <uri at arnor.uucp>
Subject: Re: at files and permissions
Date: 6 Jul 89 16:17:56 GMT
To: unix-wizards at sem.brl.mil
>From article <8072 at bsu-cs.bsu.edu>, by dhesi at 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 at eci386.uucp
Subject: Re: at files and permissions
Date: 6 Jul 89 20:47:10 GMT
To: unix-wizards at sem.brl.mil
In article <8072 at bsu-cs.bsu.edu> dhesi at bsu-cs.bsu.edu (Rahul Dhesi) writes:
>In article <669 at lzaz.ATT.COM> hutch at 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 <guy at auspex.auspex.com>
Subject: Re: at files and permissions
Date: 6 Jul 89 22:11:53 GMT
To: unix-wizards at 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 <toppin at melpar.uucp>
Subject: Convert string time into seconds?
Date: 6 Jul 89 17:42:44 GMT
Keywords: time
To: unix-wizards at 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 <samperi at marob.masa.com>
Subject: Sun calctool
Date: 6 Jul 89 18:16:22 GMT
Keywords: calctool lost
To: unix-wizards at 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 at marob.masa.com
uunet!hombre!samperi
-----------------------------
From: Jeffrey W Percival <jwp at larry.sal.wisc.edu>
Subject: Algorithm needed: reading/writing a large file
Date: 6 Jul 89 18:16:29 GMT
To: unix-wizards at 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 at larry.sal.wisc.edu)
-----------------------------
From: Ken Burch <ntm1836 at dsacg1.uucp>
Subject: Re: Information on `TUNEX' kernel tuning program
Date: 6 Jul 89 18:59:38 GMT
To: unix-wizards at sem.brl.mil
In article <1144 at vsi.COM> friedl at 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 at dsacg1.dla.mil
DLA Systems Automation Center | or
Columbus, OH | ...!osu-cis!dsacg1!ntm1836
-----------------------------
From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: Should "ls -R" traverse symlinks?
Date: 6 Jul 89 21:23:57 GMT
Keywords: symlink, find
To: unix-wizards at sem.brl.mil
In article <12377 at bloom-beacon.MIT.EDU> scs at 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 <guy at auspex.auspex.com>
Subject: Re: Environment variables at login
Date: 6 Jul 89 22:25:57 GMT
Keywords: environment login
To: unix-wizards at 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 <clewis at eci386.uucp>
Subject: Re: Cartridge tape stuff
Date: 7 Jul 89 00:34:55 GMT
To: unix-wizards at sem.brl.mil
In article <757 at mitisft.Convergent.COM> dold at mitisft.Convergent.COM (Clarence Dold) writes:
>in article <1989Jun28.173209.1457 at eci386.uucp>, clewis at 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
<ctrl-D>
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=<whatever> > /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: <cheetah at blake.acs.washington.edu>
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 at 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 <disclaimer.h> cheetah at blake.acs.wahington.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----------------------------
End of UNIX-WIZARDS Digest
**************************
---------- end of forwarded message
More information about the Comp.unix.wizards
mailing list