doug@xdos.UUCP (Doug Merritt) (09/06/89)
>Lehtinen Pertti: Unix doesn't allow you make hard links to directories. >Peter da Silva: But it does. >Ronald Minnich: The last version of Unix that allowed you to was long ago. >Fred Fish: <Example of how to link a dir> >David Donley: On HP-UX systems you have to be superuser to link directories. There seems to be a lot of confusion on the subject, so let's straighten this out. 1) Unix does not allow ordinary users to make links to directories, because of the necessity of retaining a pure tree structure. This has been true at least since 1975, and probably right from the start. 2) As part of its fundamental design, Unix implements some of its features via "trusted user processes" rather than directly in the kernel (this general approach is a feature, BTW). In particular, the process of creating a new directory inherently involves making links to directories, because the entry "." (synonym for "current directory") is created by linking the directory to the entry "." within itself. Also the entry ".." (synonym for "parent directory") is created by linking the parent directory to the entry ".." within the new directory. This is accomplished by having the "mkdir" command run as superuser, meaning it is a trusted user process authorized to implement and enforce OS design policy, so it is allowed to make such links to directories as part of the ordinary process of creating new directories. 3) The "ln" utility is just a simple wrapper around the "link" system call. On some Unix systems that's all there is to it, so that a superuser can use "ln" to link directories if he wishes. He's not a user, he's an extension of OS policy, so he's trusted to do as he pleases. Some Unix systems recognize that human beings are imperfect, and have added checking to "ln" to enforce "no links to directories" even for the superuser. Even on such systems, the superuser can write a trivial C program encapsulating the "link" system call, and use *that* to make links to directories if he really wants to. 4) A very, very few Unix systems, such as Gould's, have totally changed the way all of this sort of thing works, in the name of achieving great enough theoretical security so as to sell their systems to "secure" government facilities. Purists claim that such changes mean that it's no longer Unix (but what's in a name?) 5) Links are *not* "a slow substitute for aliases", unless you're widening the definition of "alias" to include link-like objects, in which case it's still a nonsensical statement. Off the cuff opinions about things you know nothing about are no substitute for precise reasoning about design tradeoffs. Links have both good and bad points; it reflects much better on a poster if he shows he has knowledge of those tradeoffs, not just uninformed opinions. -Doug- -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
ddave@pnet02.gryphon.com (David Donley) (09/08/89)
doug@xdos.UUCP (Doug Merritt) writes: >>Lehtinen Pertti: Unix doesn't allow you make hard links to directories. >>Peter da Silva: But it does. >>Ronald Minnich: The last version of Unix that allowed you to was long ago. >>Fred Fish: <Example of how to link a dir> >>David Donley: On HP-UX systems you have to be superuser to link directories. > >There seems to be a lot of confusion on the subject, so let's straighten >this out. > 5) Links are *not* "a slow substitute for aliases", unless you're > widening the definition of "alias" to include link-like objects, > in which case it's still a nonsensical statement. > Off the cuff opinions about things you know nothing about > are no substitute for precise reasoning about design tradeoffs. > Links have both good and bad points; it reflects much better > on a poster if he shows he has knowledge of those tradeoffs, not > just uninformed opinions. > >-Doug- >-- >Doug Merritt {pyramid,apple}!xdos!doug >Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary Links are indeed "a slow substiture for aliases". I know what links are. Hard links on the same volume have no practical use at all except to be aliases, maybe for UN*X people using sh (which still can't do aliases) Anyhow, I think soft links between volumes would be useful, but hard links - Nah... It reflects better on a poster if he doesn't make uninformed statments about other poster's abilities/knowledge/expierience... Lighten up, buddy. ---------------------------------------
doug@xdos.UUCP (Doug Merritt) (09/08/89)
In article <19619@gryphon.COM> ddave@pnet02.gryphon.com (David Donley) writes: >doug@xdos.UUCP (Doug Merritt) writes: >> 5) Links are *not* "a slow substitute for aliases", [...] >> Off the cuff opinions about things you know nothing about >> are no substitute for precise reasoning about design tradeoffs [...] >Links are indeed "a slow substiture for aliases". I know what links are. >Hard links on the same volume have no practical use at all except to be >aliases, maybe for UN*X people using sh (which still can't do aliases) ... > >It reflects better on a poster if he doesn't make uninformed statments about >other poster's abilities/knowledge/expierience... Lighten up, buddy. You're quite right about the tone of my final comment, it was inappropriate and rude. My apologies for offending you. I still disagree on the technical content, though. You mention shells. Ok, set up any kind of shell alias you like to make one directory entry a synonym for another. Now try to use that alias from another program, like an editor. The editor won't know about the alias. In other words, links (never mind whether hard or soft, the same point applies) are useful because they are universal...any program you use will be aware of the link. This isn't true of any possible kind of shell alias. (And in fact, "aliases" in the C shell apply only to commands, at that. The only way to introduce a synonym even in the C shell that will work as a parameter, not just as the command itself, is via a C shell variable, e.g. "set a=/usr/ucb/more; cp $a /tmp". Compare this with "alias a /usr/ucb/more; cp a /tmp" which won't work, and "ln [ -s ] /usr/ucb/more a; cp a /tmp" which will.) No offense intended, but I still can't understand how someone can be familiar with links and not see this basic difference between them and aliases. This astonishment is what gave rise to my heated remark. Doug -- Doug Merritt {pyramid,apple}!xdos!doug Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary
jesup@cbmvax.UUCP (Randell Jesup) (09/09/89)
In article <19619@gryphon.COM> ddave@pnet02.gryphon.com (David Donley) writes: >doug@xdos.UUCP (Doug Merritt) writes: >> 5) Links are *not* "a slow substitute for aliases", unless you're >> widening the definition of "alias" to include link-like objects, >> in which case it's still a nonsensical statement. > >Links are indeed "a slow substiture for aliases". I know what links are. >Hard links on the same volume have no practical use at all except to be >aliases, maybe for UN*X people using sh (which still can't do aliases) >Anyhow, I think soft links between volumes would be useful, but hard links >- Nah... Only from the command line. Remember both soft and hard links work from programs as well. Aliases are entirely a concept of the shell, not of the Unix system calls. Oh, and both of you please lighten up, and stick to technical comments. Thanks. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"
ddave@pnet02.gryphon.com (David Donley) (09/09/89)
doug@xdos.UUCP (Doug Merritt) writes: >In article <19619@gryphon.COM> ddave@pnet02.gryphon.com (David Donley) writes: >>doug@xdos.UUCP (Doug Merritt) writes: >>> 5) Links are *not* "a slow substitute for aliases", [...] >>> Off the cuff opinions about things you know nothing about >>> are no substitute for precise reasoning about design tradeoffs [...] > >>Links are indeed "a slow substiture for aliases". I know what links are. >>Hard links on the same volume have no practical use at all except to be >>aliases, maybe for UN*X people using sh (which still can't do aliases) ... >> >>It reflects better on a poster if he doesn't make uninformed statments about >>other poster's abilities/knowledge/expierience... Lighten up, buddy. > >You're quite right about the tone of my final comment, it was inappropriate >and rude. My apologies for offending you. > >I still disagree on the technical content, though. You mention shells. >Ok, set up any kind of shell alias you like to make one directory entry >a synonym for another. Now try to use that alias from another program, >like an editor. The editor won't know about the alias. > > Doug >-- >Doug Merritt {pyramid,apple}!xdos!doug >Member, Crusaders for a Better Tomorrow Professional Wildeyed Visionary Good point- maybe I just never thought about that, since on my Amiga, I may open another shell to type in commands, and usually never execute commands from programs other than shells. Links still don't work as very good aliases, since the program to be linked must be written to take advantage of the aliases. Perhaps the solution to this particular problem would be to fix the Execute() call so it actually starts up a shell which procedes to execute the regular shell-startup file, and THEN runs the program. Of course, I use an editor with macros, and could care less that it doesn't like my aliases... :-)