Are links as useful as they could be?

Comfy chair ken at rochester.ARPA
Sat Sep 27 13:46:11 AEST 1986


First let me make clear the context of my question, ask the question,
then explain why I ask.

I am asking about hard links, not symbolic links. The question is:  If
you were designing a new operating system, say a successor to U**x,
would you implement links in the same way, enhance it, or put more
restrictions on it?

Now my thoughts leading up to the question. When I first read how links
worked in U**x, I liked the idea. Mv was just a link() followed by
unlink(), rm was unlink(), and you could share files and have Jerkyl
and Hyde programs, &c, &c. Over the years I noticed that the
limitations were such that people couldn't use the full generality of
the concept. You couldn't link across filesystems or link directories,
so symbolic links were invented. To find out where the other links
were, you would have to search the whole filesystem, in the general
case. Utilities like tar and rdist have to remember files with links
and might run out of memory to store the filenames, in theory at
least.

One restriction that would ease the search problem is to restrict links
to the current directory.  Most uses of links are to alias things like
"vi" and "ex", "tip" and "cu" and these things usually live close
together.  This means rename would have to be made a primitive. But mv
has to do a copy when it can't do a link because link() doesn't
generalize across filesystems.

There still is obviously a need for some kind of indirection mechanism.
I don't like symbolic links, there are some warts, like having to check
for looping, but I can't think of anything better.

Do you have any ideas on this? I'd like to hear them. Please mail.  I
don't want to start an OS war.

	Ken
-- 
UUCP: ..!{allegra,decvax,seismo}!rochester!ken ARPA: ken at rochester.arpa
Snail: CS Dept., U. of Roch., NY 14627. Voice: Ken!
"It is absurd to divide people into good or bad. People are either
	charming or tedious." -- Oscar Wilde



More information about the Comp.unix mailing list