Warning From uucp
Hermes Trisgesmis
uucp at att.att.com
Sun Dec 25 21:15:51 AEST 1988
We have been unable to contact machine 'wa015b' since you queued your job.
wa015b!mail james (Date 12/23)
The job will be deleted in several days if the problem is not corrected.
If you care to kill the job, execute the following command:
uustat -kwa015bN49db
Sincerely,
att!uucp
#############################################
##### Data File: ############################
>From arpa!VM1.NoDak.EDU!BRL.MIL!UNIX-WIZARDS Fri Dec 23 14:10:15 1988 remote from att
Received: by att.ATT.COM (smail2.6 att-mt)
id AA00055; 23 Dec 88 14:10:15 EST (Fri)
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP R1.2) with BSMTP id 2266; Fri, 23 Dec 88 13:04:50 CST
Received: by NDSUVM1 (Mailer X1.25) id 2262; Fri, 23 Dec 88 13:04:45 CST
Date: Fri, 23 Dec 88 02:45:29 EST
Reply-To: UNIX-WIZARDS%BRL.MIL at VM1.NoDak.EDU
Sender: Unix-Wizards Mailing List <UNIX-WIZ at VM1.NoDak.EDU>
From: Mike Muuss The Moderator <Unix-Wizards-Request%BRL.MIL at VM1.NoDak.EDU>
Subject: UNIX-WIZARDS Digest V6#057
X-To: UNIX-WIZARDS at BRL.MIL
To: James Anderson <wa015b!james at ATT.ATT.COM>
UNIX-WIZARDS Digest Fri, 23 Dec 1988 V6#057
Today's Topics:
Re: password security
Re: Yet Another useful paper
"bibtools"
Re: Ultrix tape job is unkillable!
Re: IEEE 1003.2 (was Re: fixing rm * (was: Worm/Passwords))
rsh environment
Re: bug in pclose(3)
This is strange...
Re: libraries
Re: VERY Dangerous Hole of 4.3BSD UNIX Security !!!
Re^2: cat -u
Re: rsh environment
Re: SysVr3.2.1 /etc/mount problems
Interrupts and DEC (was Ultrix tape job is unkillable!)
Re: This is strange...
Re: Ultrix tape job is unkillable!
Re: libraries
-----------------------------------------------------------------
From: "Paul R. Haas" <prh at actnyc.uucp>
Subject: Re: password security
Date: 21 Dec 88 21:41:32 GMT
To: unix-wizards at sem.brl.mil
In article <4444 at xenna.Encore.COM> bzs at Encore.COM (Barry Shein) writes:
>The average secretary I know is bright enough to understand rules like
>"use two short words with some upper-case letters and/or digits thrown
>in and separated by a punctuation, like "Hey!Jude" "FidoIS#1". Very
>hard to guess, very easy to remember, next...
Give a thousand secretaries that same set of instructions and you will
get far less than a thousand different passwords. Sort them in order
of frequency and try them all on whatever system you are trying to
crack. You certainly won't be able to break all the accounts, but you
will get a few. Many people may prefer to listen in on a large
ethernet rather than deal with a thousand secretaries, but the result
should be the similar.
If people are allowed to create their own passwords, there should not be
a way to try ten thousand different passwords on each account with out
triggering some alarm.
If security is really important it may be usefull to put the shadow
password file on a separate server machine. The server machine should be
physically and electronically remote so that the only requests it
services are "check password/username", "add password/username",
"remove password/username" and "changepassword
newpassword/oldpassword/username". This implies that backups and restores
have to be done manually. A logical migration path to a secure password
server is to use a shadow password file which is normally only accessable
through a small well defined interface.
-----
Paul Haas uunet!actnyc!prh haas at frith.egr.msu.edu (212) 696-3653
-----------------------------
From: Operator <root at zardoz.uucp>
Subject: Re: Yet Another useful paper
Date: 21 Dec 88 03:27:49 GMT
To: unix-wizards at sem.brl.mil
In article <4420 at xenna.Encore.COM> bzs at Encore.COM (Barry Shein) writes:
>>As far as UNIX passwords, it further justifies the use of a shadow
>>password file and the use of 64 character pass phrases.
>Why? Because it shows a 20x speedup possibility? Let's do the
>arithmetic again...
>Given a 100 character character set and 8 characters in a password
>the search space is 100^8 which is:
But you don't need to search through all 100^8 combinations to have a
reasonable change of gaining entry. All you need is to search through
a 1000, or possibly even 10,000 common names and words, and you will
find a match on a surprisingly large number of systems. Under this
scenario, a 20 X speedup can make a big difference on the practicality
of sneeking in a large batch job to do some password crunching.
neil at cpd.com
uunet!zardoz!neil
-----------------------------
From: Henry Spencer <henry at utzoo.uucp>
Subject: Re: Yet Another useful paper
Date: 21 Dec 88 19:37:52 GMT
To: unix-wizards at sem.brl.mil
In article <110 at microsoft.UUCP> w-colinp at microsoft.UUCP (Colin Plumb) writes:
>My objection to shadow password files is that the layer of security they
>provide relies on the unreadability of the file by non-root people.
>Unix is not particularly secure this way...
This does somewhat depend on how alert the sysadmin is. However, I think
you're missing a point: shadow password files do add one more layer of
complication for would-be crackers. There is no such thing as perfect
security, just ways of making life harder for the bad guys.
--
"God willing, we will return." | Henry Spencer at U of Toronto Zoology
-Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry at zoo.toronto.edu
-----------------------------
From: Henry Spencer <henry at utzoo.uucp>
Subject: Re: Yet Another useful paper
Date: 21 Dec 88 19:41:32 GMT
To: unix-wizards at sem.brl.mil
In article <12750 at bellcore.bellcore.com> karn at ka9q.bellcore.com (Phil Karn)
writes:
>I too have my doubts about the effectiveness of shadow password files. My
>fear is that it will make administrators complacent; they'll reason that
>since no one can get at the file, then there's no need to ensure on a
>regular basis that people pick hard-to-guess passwords.
Turn it around: would you suggest deleting shadow password files, from
systems which already have them, just to keep the sysadmins alert? Seems
a bit drastic to me. I would think that any sensible sysadmin realizes
that password guessing via login is always a threat. And insensible :-)
sysadmins are beyond help anyway, short of massive upheaval in the software
to make it naive-sysadmin-friendly.
--
"God willing, we will return." | Henry Spencer at U of Toronto Zoology
-Eugene Cernan, the Moon, 1972 | uunet!attcan!utzoo!henry henry at zoo.toronto.edu
-----------------------------
From: Bud Hovell <bbh at whizz.uucp>
Subject: "bibtools"
Date: 20 Dec 88 19:32:15 GMT
Keywords: ...how to get?
To: unix-wizards at sem.brl.mil
Can someone tell me something about the "bibtools" (bibligraphical db)
package and how I might secure a copy? (Wasn't sure where best to post this).
Thanks,
OVERTURE SYSTEMS CORP.
Bud Hovell Operations Specialists
Lake Oswego, Oregon
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
: USENET: {attmail! | tektronix!tessi!bucket! | pacbell!safari!} whizz!bbh :
: TELEX: 152258436 (Whizz/Bud Hovell) VOICE: 503-636-3000 :
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
"Follow your bliss" - Joseph Campbell
-----------------------------
From: Dave Martindale <dave at onfcanim.uucp>
Subject: Re: Ultrix tape job is unkillable!
Date: 21 Dec 88 15:45:05 GMT
To: unix-wizards at sem.brl.mil
In article <1988Dec19.215505.3768 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer)
writes:
>>On Motorola iron, and on the
>>buses usually used with it, controllers raise an interrupt line when they
>>want attention, and the interrupt will recur until the controller is made
>>happy...
>
>Can you explain where you got the idea that the PDP11 (I can't speak for
>the VAX) does something different? Believe me, having an interrupt recur
>until the controller is happy is a well-known nuisance on the 11, and as
>far as I know (I'm not intimate with the Unibus any more), the protocol
>is entirely level-triggered.
The behaviour depends on the interrupt controller in the device.
The Unibus itself just handles requests and grants, and a device is free
to request over and over again until it's happy. However, the original
DEC interrupt controller card contained a flip-flop that was triggered
by the rising edge of an interrupt request signal (usually DONE anded with
interrupt enable) and cleared when the interrupt had been granted by
the Unibus. Later DEC devices, with all the circuitry on a single card,
retained this behaviour.
Thus, it is common to have a Unibus device driver just handle the information
passed back from the device by an interrupt without ever doing anything
to change the state of the device. The DONE or READY bit and IENABLE bits
remain set, and the software knows that the hardware will not request
another interrupt.
-----------------------------
From: Bob Lenk <rml at hpfcdc.hp.com>
Subject: Re: IEEE 1003.2 (was Re: fixing rm * (was: Worm/Passwords))
Date: 22 Dec 88 00:53:09 GMT
To: unix-wizards at sem.brl.mil
> But MY point is that "ar" is practically the ONLY UNIX utility to have been
> hammered over the years into producing a completely portable format (when
> used for text files). Even cpio -c and tar formats fail to be as portable.
Interchange formats are part of the charter of 1003.1, not 1003.2.
1003.1 standardized both cpio -c and extended tar. As far as I know, ar
format was never considered. I'm relatively sure it wasn't brought up
in anyone's ballot. It seems inappropriate for 1003.2 to attempt to
standardize ar as a better interchange format.
1003.1 is aware of limitations to extended tar and cpio, and is
considering proposals for (hopefully one) better archive/interchange
format. Inputs to the 1003 mailing list and/or working group meetings
are welcome. Informal inputs in forums like this may also prove useful.
Bob Lenk
hplabs!hpfcla!rml
rml%hpfcla at hplabs.hp.com
-----------------------------
From: Christoph Kuenkel <ckl at uwbln.uucp>
Subject: rsh environment
Date: 19 Dec 88 19:01:45 GMT
Keywords: no /etc/profile sourced?
Posted: Mon Dec 19 20:01:45 1988
To: unix-wizards at sem.brl.mil
Is there any way to alter the default environment setting used when
rsh (the bsd remote shell) executes commands?
our rsh (bull sps9 with spix os) sets up an default environment
HOME= <from passwd>
LOGNAME= <from passwd>
PATH=.:/bin:/usr/bin <hardwired>
SHELL=/bin/sh <surprisingly not from passwd>
TERM= <always empty>
any hints?
thanks, christoph
--
# include <std/disclaimer.h>
Christoph Kuenkel/UniWare GmbH Kantstr. 152, 1000 Berlin 12, West Germany
ck at tub.BITNET ckl at uwbln {unido,tmpmbx,tub}!uwbln!ckl
-----------------------------
From: Malcolm Purvis <malcolm at otc.oz>
Subject: Re: bug in pclose(3)
Date: 21 Dec 88 23:59:33 GMT
To: unix-wizards at sem.brl.mil
In article <261 at ecijmm.UUCP> jmm at ecijmm.UUCP (John Macdonald) writes:
[Stuff about pclose(3) hanging when there is more than one child...]
>Is this behaviour common to all System 5 variations? To BSD
>derivatives? SunOS? AIX? Your favourite here?
It's all of them as for as I know. See below.
>
>Is there even a good general solution? I can see only one good way
>to handle all of the variations of some routine wanting to wait for
>a specific child and getting the termination info for a different child
>instead (which will eventually be waited for - perhaps by a totally
>different routine). That would be to provide some new library routines:
>waitfor( child, &status ) and postwait( child, status ). Waitfor would
>wait for a specified child (and save information internally on any other
>children that terminate in the meantime). Postwait would allow a routine
>that had done a wait call and gotten the termination for a child that
>it didn't know to pass that info into the mechanism for saving used by
>waitfor. These routines could be used internally by pclose, system, and
>any other library routines that have waiting for a specific child as a
>part of their semantics, as well as being provided to the user as a new
>pair of library routines for building additional capabilities that include
>forked children as a part of their implementation.
>--
>--
>John Macdonald
I had to solve this problem recently for a C++ subprocess class and
as John said it stems from the inability to wait for a specific child to
die; you can only wait for the next one. The solution I came up with under
BSD4.3 was to put a structure associated with each child in a linked list
and use a SIGCHLD handler to do the actual waiting. When the signal
arrives, the wait(2) is done in the handler and the list is searched for the
pid of the dead child and, when it is found, it is marked as dead and taken
off the list. The inside of the waitfor() call would then look something
like:
while (!child.dead)
sigpause(0); /* wait for this process to die. */
*status = child.return_value;
This works wonderfully in C++ because as the child structure goes
out of scope the child process is automatically waited for, so stopping
children not having a data structure associated with it, and also each caller
gets the right return value. I don't know, however, how you could do this in
C. The only problem with all this is that is falls over if the child dies
before it gets inserted into the list (eg: The exec() fails because the
program isn't there) so care must be taken over the order of list insertion
and forking.
I hope this helps.
Malcolm Purvis (vacation student)
|||| OTC ||
ACSnet: malcolm at otc.oz
UUCP: {uunet,mcvax}!otc.oz!malcolm
Snail: GPO Box 7000, Sydney 2001, Australia
-----------------------------
From: "M. Capron" <mcapron at ektools.uucp>
Subject: This is strange...
Date: 22 Dec 88 16:19:24 GMT
Keywords: sed awk pipe
To: unix-wizards at sem.brl.mil
Here is some bizareness I found. Below is a subset of a Bourne Shell script I
am writing on a Sun 3/60 running SunOS 4.0. This segment generates dependency
lists for makefiles. Note that the egrep brackets should contain a space and
a tab.
#!/bin/sh
for i in *.c
do
#Place a list of include files in $incs seperated by spaces.
#CODE A or CODE B goes here.
echo "$i : $incs"
done
CODE A: This works.
incs=`egrep '^#[ ]*include[ ]*"' $i | awk '{printf "%s ", $2}'`
incs=`echo "$incs" | sed 's/"//g'`
CODE B: This does not work.
incs=`egrep '^#[ ]*include[ ]*"' $i | awk '{printf "%s ", $2}' | sed
's/"//g'`
With CODE B, $incs comes out to be nil. I can't figure out what the difference
is, nor do I have the patience to play with it any furthing. I present it as an
oddity to any interested parties.
Sincerely,
Mike Capron
capron at chiron.UUCP
-----------------------------
From: Rahul Dhesi <dhesi at bsu-cs.uucp>
Subject: Re: libraries
Date: 22 Dec 88 16:16:55 GMT
To: unix-wizards at sem.brl.mil
In article <15106 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
Directory scanning tended to be O(n^2). That is why 4.3BSD,
current SunOSes, and perhaps even SVR3 have name caches. It
reduces the behaviour to O(n) in most cases. Granted, O(n) is
still considerably higher than O(1)....
In the long run (4.5BSD?) perhaps a bit could be found to mark a
directory as hashed. To preserve compatibility with current utilities,
you would need a shadow directory with the hashed structure that
mimicked the current sequential list.
--
Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
-----------------------------
From: Ning Zhang <zhang at zgdvda.uucp>
Subject: Re: VERY Dangerous Hole of 4.3BSD UNIX Security !!!
Date: 21 Dec 88 16:32:45 GMT
Keywords: Everybody can become a super-user !!!
Posted: Wed Dec 21 17:32:45 1988
To: unix-wizards at sem.brl.mil
Hello Net Folks,
I have post my report to Berkeley and have got a reply from there.
Mr.K.Bostic ask me do not distribute my report any more because I
am not sure it will not be abused or further redistributed. I am very
curious that he said my analysis was wrong, but the result is true.
He said the problem is somewhere else and Berkeley will post a fix
to the net today (dec 21).
I plan to rewrite my report with correct analysis. Any comments and
suggestion are welcome.
_______ -^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-
/____ / Ning Zhang (zhang at zgdvda.uucp)
___/ / Zentrum fuer Graphische Datenverarbeitung e.V. (ZGDV)
/__ / Wilhelminenstrasse 7, D-6100 Darmstadt, F. R. of Germany
/ /____ Phone: +49/6151/1000-67 Telex: 4197367 agd d
/______/ -v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-
P.S.: I have been a part-time system manager for 5 years in China.
P.S.: But now I am working on Computer Graphics (It's my major).
P.S.: If you give me a chance, I can do the number one for you :-)
-----------------------------
From: Maarten Litmaath <maart at cs.vu.nl>
Subject: Re^2: cat -u
Date: 19 Dec 88 21:19:28 GMT
To: unix-wizards at sem.brl.mil
eirik at tekcrl.TEK.COM (Eirik Fuller) writes:
\No, I don't use sed as my login shell :-) Yes, I use cat -v; why?
\because it's there ...
`cat -v' as loginshell? But I thought one couldn't specify options to one's
loginshell in /etc/passwd? :-)
--
fcntl(fd, F_SETFL, FNDELAY): |Maarten Litmaath @ VU Amsterdam:
let's go weepin' in the corner! |maart at cs.vu.nl, mcvax!botter!maart
-----------------------------
From: Dave Cohrs <dave at cs.wisc.edu>
Subject: Re: rsh environment
Date: 22 Dec 88 20:47:34 GMT
Sender: news at spool.cs.wisc.edu
Keywords: no /etc/profile sourced?
To: unix-wizards at sem.brl.mil
> Is there any way to alter the default environment setting used when
> rsh (the bsd remote shell) executes commands?
Are you *sure* you're using the BSD rsh (don't forget about the rshd
on the remote side), and not some Wollongong hacked up version that runs
on a SysV machine? Seeing that LOGNAME in your environment leads me to
wonder...
The rsh I use between two real BSD systems gives me an environment with
HOME, SHELL, PATH, and USER, and, because I use /bin/csh for a shell,
runs my .cshrc, which sets whatever other environment variables I want.
SysV's /bin/sh only runs your /etc/profile or your own .profile when
you log in, and a remote shell is not the same thing as logging in.
I guess if the remote machine is not a real BSD machine, or your shell
is csh, you can't easily change your environment. You can, of course
rsh a command like (assume your remote shell is /bin/sh or ksh):
rsh somemachine "FOO=$FOO command args"
and set one or more remote envariables to be the same as they were on
your local shell (assuming you had a envariable FOO in your local shell).
The variations on this theme are endless. You can also:
rsh somemachine ". .profile ; command args"
There are no provisions in the rsh protocol to automatically copy your
environment to the remote shell.
dave cohrs
--
Dave Cohrs
+1 608 262-6617 UW-Madison Computer Sciences Department
dave at cs.wisc.edu ...!{harvard,rutgers,ucbvax}!uwvax!dave
-----------------------------
From: "Vincent C. Hatem" <vch at attibr.uucp>
Subject: Re: SysVr3.2.1 /etc/mount problems
Date: 22 Dec 88 20:41:36 GMT
To: unix-wizards at sem.brl.mil
In article <1279 at nusdhub.UUCP>, rwhite at nusdhub.UUCP (Robert C. White Jr.)
writes:
] in article <76 at attibr.UUCP>, vch at attibr.UUCP (Vincent C. Hatem) says:
] >
] > After installing the OS, I installed the 4.1 C compiler. The INSTALL
procedure
] > says that I have to install the System Header Files package again... No
] > problem, I figure... Yeah, right.
]
]
] The 4.1 C compiler has a routine in it which want's you to install the
] system headder files, it *INSISTS* that you do so via floppy. 3.2.1
] does not have a System headder files floppy diskette, it is on tape,
] so you try to load these things from tape. sysadm installpkg has the
so far, so good...
] floppy mounted on the directory /install and sysadm tapepkg wants to
] mount the partition of the tape which contains the system headder files
] in the directory /install. here is our basic conflict... ;-)
Not quite. I broke the installation at that point. The floppy was NOT mounted.
That's the first thing I checked...
] To check this out for yourself jsut "mount -r /dev/rSA/diskette1 /install"
I tried that. Didn't work.
] Does this sound like someone who has already been through all this? IT
] SHOULD! I spent the better part of the day disecting the diskettes just
] to make shure. ACK.
]
] Rob.
Sorry to hear that you went to so much trouble no to be able to help me at
all... ;-} ;-} ;-} ;-} ;-} ;-}
Seriously, I DO appreciate your help. I found the problem myself. The
partition was flagged as non-mountable. 3.1.1 doesn't care, but 3.2.1 DOES.
Basically, I made a type while editing the partition maps.
OOPS.
It works now that I re-partitioned the disk.
--
Vincent C. Hatem | att ---->\ (available from any
AT&T International | ulysses ->\ Action Central site)
International Operations Technical Support | bellcore ->\___ !attibr!vch
1200 Mt Kemble Ave, Basking Ridge, NJ 07920 | (201) 953-8030
-----------------------------
From: Chris Torek <chris at mimsy.uucp>
Subject: Interrupts and DEC (was Ultrix tape job is unkillable!)
Date: 22 Dec 88 19:45:06 GMT
To: unix-wizards at sem.brl.mil
In article <16971 at onfcanim.UUCP> dave at onfcanim.UUCP (Dave Martindale) writes:
>Thus, it is common to have a Unibus device driver just handle the information
>passed back from the device by an interrupt without ever doing anything
>to change the state of the device. The DONE or READY bit and IENABLE bits
>remain set, and the software knows that the hardware will not request
>another interrupt.
Right---for some devices, the sequence for (e.g.) a UART DONE interrupt
is:
if (buf->count) {
dev->xmit = *buf->ptr++;
buf->count--;
} else
dev->ctl &= ~INTERRUPT_ENABLE;
but for typical DEC hardware one can leave out the `else' step. It
does not really save anything, as you then must keep track of busy/
not-busy yourself:
/* start DEC-style UART */
if ((softstate & BUSY) == 0) {
dev->xmit = *buf->ptr++;
buf->count--;
softstate |= BUSY;
}
/* else let interrupt handle it */
interrupt:
if (buf->count) {
dev->xmit = *buf->ptr++;
buf->count--;
/* BUSY still on */
} else
softstate &= ~BUSY;
The ugly case is where you need to turn off interrupt enable, but you
cannot *read* interrupt enable, so that you need need the software state
anyway. (Actually, since reading from a device often interferes with
the operation of that device---now that everything is microprocessor
driven---you may *still* want the software state.)
--
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: Michael "Ford" Ditto <ditto at cbmvax.uucp>
Subject: Re: This is strange...
Date: 23 Dec 88 01:59:48 GMT
Keywords: sed awk pipe
To: unix-wizards at sem.brl.mil
In article <1652 at ektools.UUCP> mcapron at ektools.UUCP (M. Capron) writes:
>CODE A: This works.
>incs=`egrep '^#[ ]*include[ ]*"' $i | awk '{printf "%s ", $2}'`
>incs=`echo "$incs" | sed 's/"//g'`
>
>CODE B: This does not work.
>incs=`egrep '^#[ ]*include[ ]*"' $i | awk '{printf "%s ", $2}' |
sed 's/"//g'`
>
>With CODE B, $incs comes out to be nil.
echo outputs a newline after its arguments, while your awk program won't.
sed only processes lines that are properly newline-terminated.
--
-=] Ford [=-
"The number of Unix installations (In Real Life: Mike Ditto)
has grown to 10, with more expected." ford at kenobi.cts.com
- The Unix Programmer's Manual, ...!sdcsvax!crash!elgar!ford
2nd Edition, June, 1972. ditto at cbmvax.commodore.com
-----------------------------
From: Guy Harris <guy at auspex.uucp>
Subject: Re: Ultrix tape job is unkillable!
Date: 22 Dec 88 23:49:00 GMT
Keywords: ultrix tapes
To: unix-wizards at sem.brl.mil
>Of course, there is a bug.
Note, though, that the bug may be the lack of a timeout for some
operations, rather than something the driver explicitly does to lose an
interrupt; there may well be hardware botches that permanently lose
completion interrupts.
-----------------------------
From: Larry Campbell <campbell at redsox.uucp>
Subject: Re: libraries
Date: 23 Dec 88 05:00:28 GMT
To: unix-wizards at sem.brl.mil
Why not keep directories sorted? In SysV filesystems this is easy and
relatively inexpensive, since you can assume a fixed 16 bytes per name.
I am also assuming that lookups outnumber creations to a huge degree,
which I'm sure is the case.
Then namei becomes a binary search.
It also means ls doesn't need to sort things any more.
--
Larry Campbell The Boston Software Works, Inc.
campbell at bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list