dgk@ulysses.UUCP (06/04/87)
If you type
cd /usr/include/sys
echo cwd=$cwd
/bin/pwd
cd ..
echo cwd=$cwd
/bin/pwd
from csh with BSD 4.3 running on our vax you get:
cwd=usr/include/sys
/usr/sys/h
cwd=/sys
/usr/sys
If you do the equivalent
cd /usr/include/sys
/bin/pwd
echo cwd=$PWD
cd ..
echo cwd=$PWD
/bin/pwd
from the Korn shell with BSD 4.3 running on our vax you get:
cwd=/usr/include/sys
/usr/include/sys
cwd=/usr/include
/usr/include
If you do the nearly equivalent
cd /usr/include/sys
pwd
/bin/pwd
cd ..
pwd
/bin/pwd
from the 4.3 Bourne shell you get:
usr/include/sys
usr/include/sys
/usr/sys/h
/sys
I think that the reason for this discrepancy is that the implementation
of symbolic links on BSD Unix is a botch.
In order to use a system with symbolic links without being surprised,
you have to be aware of all symbolic links to directories. The reason
is that the kernel does not keep track of the device-inodes as you
descend the file tree, so it does not know how to walk back up.
For example, if I add a directory of include files named /usr/include/local
and one of my include files includes ""../stat.h", it will not work on
BSD but will work on Sys V.
Can you imagine what Unix would have been like if .. were not handled
specially at mount points? You would have to know where each of the
mount points were. Two systems could be compatible only if they had
identical mount points.
I recently added symbolic links to my version of System V Release 3
kernel. I made sure that .. was always handled like an operator that
moves you up one level. The changes were not complex and I have not
run into any problems at all. The user again sees the file system as
a tree structure which preserves the original simplicity of the Unix model.
By the way, I did modify find so that you can specify a virtual walk
or a physical walk. I virtual walk follows symbolic links. The virtual
walk keeps track of device-inodes so that I never descend through the
same physical directory more than once. Therefore, a symbolic line to
/ poses no problem.
( Now some guru might say that . and .. are just names that have
i-nodes associated with them just like any other name and therefore, the
i-node should be followed. If this were true, then as root I should
be able to edit my directory and change the inode of . to change its
meaning. What do you think really happens?)
I am conducting a poll on this issue and I am interested in hearing your views.
I will post the results to this newsgroup on the net.
What would be the best semantics for ..?
Do you think that BSD has done it right or have I done it right?
What code would break if .. were always treated as an operator?
Disclaimer: I am not affiliated with the System V product, I am involved
in research only and these are my own. They do not imply any direction
for future releases of System V.
David Korn
{ihnp4,decvax}ulysses!dgkgwyn@brl-smoke.UUCP (06/05/87)
In article <2629@ulysses.homer.nj.att.com> dgk@ulysses.homer.nj.att.com (David Korn[eww]) writes: >I recently added symbolic links to my version of System V Release 3 >kernel. I made sure that .. was always handled like an operator that >moves you up one level. The BRL SVR2 Bourne shell can be configured to handle symbolic links either way insofar as "cd" and "pwd" go. I always build it to act the way the Korn shell does, so that "cd .." never drops me into a surprising place. To really address this problem fully satisfactorily, however, one does need to make the kernel keep track of the path used to reach the current working directory, as well as have ".." handled specially. It is no longer guaranteed that one will get the "." and ".." entries when reading a directory (using POSIX-compatible access routines), so if you elect to not return a ".." entry in a directory you need not even play the tricks with its inode number needed to make the revised ".." semantics work right. I think you (David Korn) got it exactly right. Symbolic links are useful (thanks, Dennis!), but the deviation from strict hierarchical directory structure was a major problem with them. A system with a sensible notion of current working directory such as you appear to have would be best. Please send the work to the Summit folks so we can get good symlink support into SVRn (n > 3.1).
rbj@icst-cmr.arpa (Root Boy Jim) (06/06/87)
I think that the reason for this discrepancy is that the implementation
of symbolic links on BSD Unix is a botch.
I think the key word here is "the". The kernel implements symbolic
links as you describe below; the csh maintains $cwd symbolicly. If you
do `cd /foo/bar' where /foo/bar -> /whiz/bang followed by `cd ..',
$cwd gives /foo while pwd gives /whiz. Thus csh is interpreting `..'
to mean `back' while the kernel takes it to mean `up'.
In order to use a system with symbolic links without being surprised,
you have to be aware of all symbolic links to directories. The reason
is that the kernel does not keep track of the device-inodes as you
descend the file tree, so it does not know how to walk back up.
As you mention, the kernel has no sense of history (is it thus condemned
to repeat it? :-), whereas the csh does. This is mentioned in the bugs
section.
For example, if I add a directory of include files named /usr/include/local
and one of my include files includes ""../stat.h", it will not work on
BSD but will work on Sys V.
Can you imagine what Unix would have been like if .. were not handled
specially at mount points? You would have to know where each of the
mount points were. Two systems could be compatible only if they had
identical mount points.
It would be like Version 6, right? I think `cd ..' didn't work at
the `root' of a mounted file system.
I recently added symbolic links to my version of System V Release 3
kernel. I made sure that .. was always handled like an operator that
moves you up one level. The changes were not complex and I have not
run into any problems at all. The user again sees the file system as
a tree structure which preserves the original simplicity of the Unix model.
There is no way you can simulate a tree unless you ignore symbolic links,
because it no longer *is* a tree. It is a directed graph, possibly with
loops. In fact, symbolic links are no worse than when root makes links
between directorys. The possibility exists for loops, and the notion of
`up' is relative to the original directory, because it was made with
mkdir, which created the `..' entry, whereas the replicant was made
exactly like a regular link, merely adding an entry in *it's* parent
directory and bumping the target inode link count. It remains childless,
in the sense that it is no one's parent.
By the way, I did modify find so that you can specify a virtual walk
or a physical walk. I virtual walk follows symbolic links. The virtual
walk keeps track of device-inodes so that I never descend through the
same physical directory more than once. Therefore, a symbolic line to
/ poses no problem.
What you do with find has nothing to do with what the kernel thinks.
Find's job is to make some sense out of `everything in this subtree',
while the kernel only cares how to get from here to there, one level
at a time. Ignoring symbolic links turns the graph back into a tree;
consider what tar does with symbolic links. It merely records their
presence; it does not descend into any subdirectorys or recopy any files.
Alternatively, considering them as first class citizens can flatten
a graph into a tree (with various files or subdirectorys replicated
as long as there are no loops). There are useful interpretations for both.
( Now some guru might say that . and .. are just names that have
i-nodes associated with them just like any other name and therefore, the
i-node should be followed. If this were true, then as root I should
be able to edit my directory and change the inode of . to change its
meaning. What do you think really happens?)
Whoa! It is a long way from playing with the meaning of . and .. to
editing directory as if they were files. Consider the `link' and
`unlink' programs, main(c,v)char**v;{link(v[1],v[2]);} and
main(c,v)char**v;{unlink(v[1]);} respectively. Now try `unlink .'
followed by `link . <something random>' followed by `cd .' followed
by `/bin/pwd'. Don't be surprised if you get something random. Similarly
for `..'. The kernel doesn't give a hoot, but you and I and fsck do.
What would be the best semantics for ..?
Exactly what they are now as far as the kernel is concerned.
Do you think that BSD has done it right or have I done it right?
At the next conceptual level, i.e. that of the shell, i.e. what
happens when you type `cd ..', I can see several alternatives.
Possibly the best is to not treat it specially. Alternately, one
could consider it to be "rindex(cwd,'/')[0]=0; chdir(cwd)".
What code would break if .. were always treated as an operator?
What do you mean by operator? `UP', or `BACK'? Or something else?
consider the case of loops, where after `descending' into the same
directorys a few times and realizing what happened, do you want to
retrace your steps in reverse, or go straight up as fast as possible.
In the former case, `..' has a time dependent meaning.
Disclaimer: I am not affiliated with the System V product, I am involved
in research only and these are my own. They do not imply any direction
for future releases of System V.
Likewise :-)
Perhaps I can sum up by saying that symbolic links are fraught with
paradoxes; that even their creators have not addressed. They are much
like trap doors. However, they are useful enuf to be suffered their
anomalys. I hope I can live up to that standard.
David Korn
{ihnp4,decvax}ulysses!dgk
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688arnold@emory.UUCP (06/07/87)
In article <5962@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <2629@ulysses.homer.nj.att.com> dgk@ulysses.homer.nj.att.com (David Korn[eww]) writes: >>I recently added symbolic links to my version of System V Release 3 >>kernel. I made sure that .. was always handled like an operator that >>moves you up one level. > >The BRL SVR2 Bourne shell can be configured to handle symbolic links >either way insofar as "cd" and "pwd" go. I always build it to act >the way the Korn shell does, so that "cd .." never drops me into a >surprising place. This can actually be a run time decision instead of compile time; the shell diffs I posted two years ago from "gatech" did it that way. >To really address this problem fully satisfactorily, however, one >does need to make the kernel keep track of the path used to reach >the current working directory, as well as have ".." handled specially. The kernel need only keep track of the next to last component of the pathname used to get into the current directory, not the whole path name. This would allow ".." to work, although it could admittedly cause /bin/pwd to give suprising results in some cases. In fact, I don't see how the kernel's keeping the full path would help with /bin/pwd. >I think you (David Korn) got it exactly right. Symbolic links are >useful (thanks, Dennis!), but the deviation from strict hierarchical >directory structure was a major problem with them. A system with >a sensible notion of current working directory such as you appear to >have would be best. Please send the work to the Summit folks so we >can get good symlink support into SVRn (n > 3.1). Amen. To change the subject slightly; it has always struck me as wierd that the mode bits on a symbolic link have absolutely no relevance to anything; if a symlink is created with mode 000, you can still do a readlink on it! The problem is, I can't come up with decent semantics for the mode bits. (I.E. I think the current semantics are wrong, but I can't come up with anything better.) How does the Ninth Edition handle it? Comments, anyone? -- Arnold Robbins CSNET: arnold@emory BITNET: arnold@emoryu1 ARPA: arnold%emory.csnet@csnet-relay.arpa UUCP: { akgua, decvax, gatech, sb1, sb6, sunatl }!emory!arnold
ekrell@hector.UUCP (06/07/87)
In article <7724@brl-adm.ARPA> rbj@icst-cmr.arpa writes: >I think the key word here is "the". The kernel implements symbolic >links as you describe below; the csh maintains $cwd symbolicly. If you >do `cd /foo/bar' where /foo/bar -> /whiz/bang followed by `cd ..', >$cwd gives /foo while pwd gives /whiz. Thus csh is interpreting `..' >to mean `back' while the kernel takes it to mean `up'. So the question is: where should you end up?. Ignore for a moment the problem of where this special treatment of ".." belongs (shell, kernel, etc). The question is: if a user does a "cd /foo/bar" and then "cd ..", is it reasonable to expect to be in /foo whether /foo/bar is a symbolic link or not?. >In fact, symbolic links are no worse than when root makes links >between directories. The possibility exists for loops The kernel will detect a loop with symbolic links when the count of symbolic links being encountered by namei() while translating a filename exceeds some constant (8, I think). > > What would be the best semantics for ..? > >Exactly what they are now as far as the kernel is concerned. The problem ("cd /foo/bar; cd ..") still remains, then. You could argue that the special treatment for ".." belongs in the shell, but then what about a program that does a chdir or the C preprocessor searching for "../x.h" ? We would really have to change all the programs that deal with filenames and put special code in them to deal with "..". This is clearly wrong. >what happens when you type `cd ..', I can see several alternatives. >Possibly the best is to not treat it specially. Why?. A user that does "cd /foo/bar" and then "cd .." expects to be in /foo. He/she doesn't know and DOESN'T NEED to know that /foo/bar is a symbolic link. Naive users don't even know what symbolic links are. >consider the case of loops, where after `descending' into the same >directorys a few times and realizing what happened, do you want to >retrace your steps in reverse, or go straight up as fast as possible. Let the kernel deal with the loops. As I said before, after a number of symbolic links are encounteres, it gives up with an ELOOP error. Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
davel@hpisoa1.HP.COM (Dave Lennert) (06/08/87)
One problem with making ".." an operator and retrace the symbolic link path rather than the "hard link" path is that, if you cd to a directory via a symbolic link and then proceed to compile some C source which does a #include "../foo/bar.h", then you may not find the same (or any) include file. Similar problems arise with tags files. Such a context sensitive interpretation of ".." would make it impossible to reliably setup such things. Symbolic links are mainly a facility to get around certain unix limitations such as: you can only mount a file system at one mount point at a time (and hence all the disk space has to be used in one file subtree). It allows programs with hardcoded pathnames to traverse (one-way) and get to files even when the sysops need to place the files elsewhere. I applaud what you're trying to do, though. -Dave Lennert HP ihnp4!hplabs!hpda!davel
dave@murphy.UUCP (Snipe Hunter) (06/10/87)
Hmmm...I've never had much trouble with this. I have been surprised before by
passing through a symbolic link when cd'ing, and finding myself in a totally
different place, but on my personal annoyance scale it doesn't rank nearly
as high as, say, the backwards arguments to strcpy.
Treating ".." as an operator in the shell's cd command does sound like a
nice idea, though. I assume you would have some sort of a stack of
directory names and use that to handle "..". As long as it doesn't create
a directory-depth limitation, fine. You might want to consider making it
an option, turned on and off by setting a variable or something. I would
also like to see an option to have the shell issue a warning message
whenever you pass through a symlink.
I'm not so sure I feel comfortable with treating ".." specially in the
kernel, though. The reason is that, if you do that, then if you have
a symlink which contains ".." in its resolution path, the place that ".."
refers to can be different depending on how you got there. Here's an
example: you have a directory "/foo" which contains a file "f.c". This
file is a symbolic link that points to "../bar/f.c". Now, if you cd
into "/foo" without passing through a symlink, there is no problem with
"f.c"; if you more it, you get the contents of "/bar/f.c". However,
now suppose you have another directory "/xyzzy" with a symlink "plugh"
which points to "/foo". If I understand your proposal correctly, if you
cd to "/xyzzy" and then to "plugh", getcwd will report that your current
directory is "/xyzzy/plugh", not "/foo". The problem comes when you try
to access "f.c"; the symlink will refer not to "/bar/f.c", but to
"/xyzzy/bar/f.c", which doesn't exist.
Does this make sense, or have I misunderstood you completely?
---
"Country beats the hell out of me" -- Jerry Dale McFadden
Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
[Ignore header, mail to these addresses]
UUCP: ...!{sun,pur-ee,brl-bmd,seismo,bcopen,rb-dc1}!gould!dcornutt
or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt
ARPA: dcornutt@gswd-vms.arpa
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."hp@beta.UUCP (06/11/87)
In article <390@murphy.UUCP>, dave@murphy.UUCP (Snipe Hunter) writes: > > I'm not so sure I feel comfortable with treating ".." specially in the > kernel, though. The reason is that, if you do that, then if you have > a symlink which contains ".." in its resolution path, the place that ".." > refers to can be different depending on how you got there. Here's an I agree -- but, on the other hand, it *would* sometimes be nice to be about to treat ".." as the "back" operator (I assume "back" means follow the path I took to get there, whereas "up" means go up one level from where I am now regardless of how I got there?) So why not create another operator -- ",,"? (Or call it whatever you like.) You could define ".." to be the "back" operator, while ",," is "up". That way, users who don't know about symlinks can use ".." naively, and users who are worried about links to things like ../include/f.h can use ,,. You get a choice. > Does this make sense, or have I misunderstood you completely? > > Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL > [Ignore header, mail to these addresses] > UUCP: ...!{sun,pur-ee,brl-bmd,seismo,bcopen,rb-dc1}!gould!dcornutt > or ...!{ucf-cs,allegra,codas,hcx1}!novavax!gould!dcornutt > ARPA: dcornutt@gswd-vms.arpa Makes sense to me -- but I'll always take the system which lets me choose (that's why I use Unix, where I can choose between shells and windowing systems, instead of staying on a Mac or something). .. ...Akkana Center for Nonlinear Studies, LANL akkana%cnls@lanl.gov hp@lanl.gov ihnp4!lanl!hp "I think I'll take a walk. Hmm, wonder where this wire goes?" -- Max Headroom
ekrell@hector.UUCP (06/11/87)
In article <2075@emory.UUCP> arnold@emory.UUCP (Arnold D. Robbins {EUCC}) writes: >The kernel need only keep track of the next to last component of the >pathname used to get into the current directory, not the whole path >name. This would allow ".." to work, But "../.." will not. You do need the entire path name if you want to do it right all the way. >although it could admittedly >cause /bin/pwd to give suprising results in some cases. In fact, I don't >see how the kernel's keeping the full path would help with /bin/pwd. It won't. What you do then is you make pwd a shell-builtin (like in ksh), that just echoes $PWD or $cwd or whatever. Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
John_M@spectrix.UUCP (John Macdonald) (06/11/87)
In article <2200015@hpisoa1.HP.COM> davel@hpisoa1.HP.COM (Dave Lennert) writes: 1 >One problem with making ".." an operator and retrace the symbolic link 1 >path rather than the "hard link" path is that, if you cd to a directory 1 >via a symbolic link and then proceed to compile some C source which does 1 >a #include "../foo/bar.h", then you may not find the same (or any) include 1 >file. > >Similar problems arise with tags files. > >Such a context sensitive interpretation of ".." would make it impossible >to reliably setup such things. > 2 >Symbolic links are mainly a facility to get around certain unix limitations 2 >such as: you can only mount a file system at one mount point at a time (and 2 >hence all the disk space has to be used in one file subtree). It allows 2 >programs with hardcoded pathnames to traverse (one-way) and get to files 2 >even when the sysops need to place the files elsewhere. > >I applaud what you're trying to do, though. > >-Dave Lennert HP ihnp4!hplabs!hpda!davel I started to use paragraph 1 above as the basis of this followup. In the process of writing my comments, my thoughts changed so that I strongly support paragraph 2 above instead. I was intending to say that there are times when you want ".." to be a reference to the hard parent, and times when you want a reference to the soft parent, but that for a given soft link, you usually want the same parent for ALL references relative to it. Thus if an extension to soft links was made whereby at the time of creating the soft link you also specified whether it was a soft-parent-.. or a hard-parent-.. form of soft link and then the kernel would arrange either one for you. However, I then thought that once you have set up and used both of these forms for their appropriate purposes, then it would start to seem quite reasonable to want both parents available. (e.g. you run make in a soft-linked directory - you want <#include "../h/foo.h"> to go to the hard ../h, but you want <cc .... ../lib ....> to go through the soft link to your newly written version of the library - the one that you are trying to test.) This leads to wanting more versions of soft-links: "search order is: soft link only for write, soft link first and hard link second for read" and its 5000 nearly identical brethren. The concept of the soft link is a wart on the Unix file system. It is elegant, powerful, and valuable, but a wart none the less. It contravenes the important principle that ". and .. are the only circular links". This principle is an implicit assumption of much of the software on Unix systems and of most of the users. It is often used in ported source code (#include "../h/foo.h" as mentioned above). Thus, I am lead to the conclusion that soft-links to directories should be avoided in places where .. is going to be used. It is too likely to cause problems that are hard to notice and diagnose. (I can imagine an entry in the risks forum about a system that was released after successfully passing a complete test suite, except that because of an forgotten soft link, the test suite was linked and run using the old proven production library instead of the new freshly compiled library that was supposed to be getting tested.) The only system that I have access to that provides soft links specifies that soft links to a directory may only be done by the super-user. It would appear that other people have come to the same conclusion. (I presume that this is a standard restriction on all systems with soft links. If not, then perhaps it should be.) -- --------- .signature eater food --------- John Macdonald UUCP: {mnetor,utzoo} !spectrix!jmm internet:Sorry. We're in range, but we're in no domain. Disc-claimer: (noun) any hack's source directory
jas@rtech.UUCP (06/11/87)
Minor point relating to this discussion: it's not symbolic links
per se that are a botch, it's allowing links (symbolic or not)
to directories. As soon as you do that, the file name space changes
from a tree to a dag, so there is no longer a unique path "up" to
the root (i.e., ".." becomes ambiguous). Regardless who keeps track
of the path you took to a particular node -- shell or kernel -- ".."
may not mean what you want it to mean (didn't somebody mention "../path"
in "#include" directives?)
--
Jim Shankland
..!ihnp4!cpsc6a!\
rtech!jas
..!ucbvax!mtxinu!/cds@lrt20.UUCP (06/11/87)
One big proble with making .. back up symbolic links is it would lose what I consider to be one of the biggest uses of symbolic links. I have a directory full of symbolic links pointing at various useful places around a quite complex tree, these symbolic links are named as mnemonics for the various places they point at and the directory containing them is included in my CDPATH. I then can say "cd <mnemonic for somewhere close>/../<where I really want to be>" without having to type in lengthy pathnames. Chris Seabrook MAIL: cds@root.co.uk SNAIL: Root Computers, Saunderson House, Hayne Street, London EC1A 9HH PHONE: +44 1 606 7799
vandys@Lindy.STANFORD.EDU (Andy Valencia) (06/11/87)
In article <898@rtech.UUCP> jas@rtech.UUCP (Jim Shankland) writes: >As soon as you do that, the file name space changes >from a tree to a dag ^^^ Actually, it can have cycles (see ELOOP), so it's even worse than you thought! But until I can think up something more satisfying, I'm not going to take pot shots at it. After all, it sure has come in handy on occasion. Andrew Valencia vandys@lindy.stanford.edu br.ajv@rlg.BITNET
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (06/11/87)
I sent a *much* longer version of this to David Korn directly, but I
thought I would post a summary of my thoughts to the net. I have my
flame suit on.
Problems:
a) permissions - ignore, new meaning, ?
b) loops?
c) links to files, directories?
d) links to FIFOs (this is SysV)
Possible area(s) of better solution:
Could a special form of the mount call be used to mount one
subdirectory in another? UNIX really knows how to handle mounts, so it
shouldn't unduely confuse applications and backups.
Would this effect the .. problem, for better or worse?
--
bill davidsen (wedu@ge-crd.arpa)
{chinet | philabs | sesimo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mesnoopy@doghouse.gwd.tek.com (Snoopy) (06/12/87)
In article <898@rtech.UUCP> jas@rtech.UUCP (Jim Shankland) writes: >Minor point relating to this discussion: it's not symbolic links >per se that are a botch, it's allowing links (symbolic or not) >to directories. But, *not* allowing symlinks to directories would be a botch! Everyone repeat after me: "Everything is a file." Symlinks to directories (like RCS directories on remote machines) are extremely useful. Symlinks to 'special' files (like tape drives on remote machines) are very useful. I almost never make symlinks to 'regular' files. Yes, the "cd .." and "pwd" stuff can get a bit confusing when you're lost in a twisty mazy of symbolic links, all different. How about adding options to cd and pwd (and whatever) to specify going up rather than back? [yeah, I know, Yet Another Option :-( ] Sometimes it would be handy to get pwd to tell you both paths. As far as permissions of symlinks go, it would be nice to be able to change them so that they can be made to blend in and not show up when doing, say, a "find -perm". Even if they continue to not mean anything. Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com
ekrell@hector..UUCP (Eduardo Krell) (06/13/87)
In article <6233@steinmetz.steinmetz.UUCP> davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr) writes: >Problems: > a) permissions - ignore, new meaning, ? > b) loops? > c) links to files, directories? > d) links to FIFOs (this is SysV) I don't see how these things are related to the treatment of ".." in a different way. If this are general arguments against adding symbolic links to System V, then the answers are: a) You need read permission on the symbolic link itself and then whatever permissions you require are matched against the file/directory/whatever the link is pointing to. b) The kernel as a built-in limit on the number of symbolic links it can expand while translating a given pathname. This handles loops. c) Yes, yes. d) Why not?. A Symbolic link is an abstraction that can point to anything. The idea is to extend the hard link mechanism to allow for links to cross file system boundaries. Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
gwyn@brl-smoke.UUCP (06/14/87)
I should perhaps report that Dennis Ritchie implemented symlinks first, but doesn't take sole credit for the idea, which came up in a group discussion at Berkeley. He also doesn't much like Korn's idea of "..", on the grounds that it adds structural complexity. My counter-argument is that the strict directory hierarchy is such an important idea that it should take precedence when there are conflicting possibilities; for example, an RFS server will pass back evaluation of a pathname to the client when a ".." path component crosses over a remote-mount point. (So there is precedent for Korn's handling of "..".) I hope I haven't misrepresented what Dennis told me last week.
gwyn@brl-smoke.UUCP (06/14/87)
In article <5984@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >... on the grounds that it adds structural complexity. My counter-argument >is that the strict directory hierarchy is such an important idea that it ... Upon re-reading my previous posting, I noticed that I didn't make clear what to me is the telling point: The Korn handling of ".." makes the file system appear at least LOCALLY hierarchical, even though GLOBALLY it's not. Since ".." normally has use only for such local behavior, Korn's approach seems appropriate for it. The argument someone supplied about the contents of a symlink being "../foo" doesn't seem relevant if the "../foo" is interpreted relative to the actual current directory containing the symlink; the pathname involved in the open() (or stat() or whatever) should not be affected by the contents of any symlinks encountered along the way. Proper local handling of .. within a symlink is thus different from proper handling of .. in the user pathname context.
eichin@bloom-beacon.UUCP (06/14/87)
In article <359@root44.co.uk> cds@lrt20.UUCP (Chris Seabrook) writes: >... >I consider to be one of the biggest uses of symbolic links. I have a directory >full of symbolic links pointing at various useful places around a quite >complex tree, these symbolic links are named as mnemonics for the various >places they point at and the directory containing them is included in my >CDPATH. I then can say "cd <mnemonic for somewhere close>/../<where I really >want to be>" without having to type in lengthy pathnames. Yes. Exactly. One contention I have recently had with GNUemacs is that it refuses to resolve .. as the parent of the directory at the other end of this symlink, but rather as the previous component of the name. If I wanted to come back up the name, I would just type "Meta-DEL" in the filename window, and be back at the top of the link. This way I would have a clear choice of which type of parent I want. Unfortunately, it is not implemented that way; no one in comp.emacs has suggested patches, and I don't have time to fix it myself. /Happy Hacking........\\.............Mark Eichin/ <eichin@ATHENA.MIT.EDU><SIPB member & Watchmaker>
jas@rtech.UUCP (06/15/87)
In article <8689@tekecs.TEK.COM> snoopy@doghouse.gwd.tek.com (Snoopy) writes: >In article <898@rtech.UUCP> jas@rtech.UUCP (Jim Shankland) writes: >>Minor point relating to this discussion: it's not symbolic links >>per se that are a botch, it's allowing links (symbolic or not) >>to directories. > >But, *not* allowing symlinks to directories would be a botch! >Everyone repeat after me: > > "Everything is a file." Original point was only that it is not the "symbolic-ness" of the link that is at issue; all the complaints about symbolic links (whether or not they are justified) are really complaints about links to directories. Repeating that everything is a file, whether or not it is true, is not a useful exercise. A terminal is a file, but I can't seek on it; a (vanilla) pipe is a file, but I can neither seek on it nor name it; /etc/passwd is a file, but I can't mount it; the swap partition is a file, but I can't put it into cbreak mode; and so on. > >Symlinks to directories [examples omitted] ... are extremely useful.... > >Yes, the "cd .." and "pwd" stuff can get a bit confusing.... How about >adding options to cd and pwd (and whatever) to specify going up rather >than back? [yeah, I know, Yet Another Option :-( ] Sometimes it would >be handy to get pwd to tell you both paths. In general, having turned the name space into a dag (graphs with cycles, not being well-formed name spaces, are not considered), there may be more than two ways "up;" "pwd" could output arbitrarily many paths. Sure, links to directories are useful; but they also lead into a semantic swamp. I'm not advocating a particular solution (don't have one); just trying to clarify the problem. -- Jim Shankland ..!ihnp4!cpsc6a!\ rtech!jas ..!ucbvax!mtxinu!/
guy@gorodish.UUCP (06/15/87)
Disallowing symbolic links to directories simply won't fly. For one
thing, it's difficult, if not impossible, to forbid:
$ >foo # create plain file
$ ln -s foo bar # make "bar" a symlink to "foo"
$ rm foo; mkdir foo # now "bar" is a symlink to a directory
or
$ ln -s foo bar # make "bar" a symlink to a nonexistent file
$ mkdir foo
Disallowing symbolic links to nonexistent files - or, in fact, doing
ANY checking of the contents of the symbolic link - would tick off a
lot of people. For example, I think the ISIS user-level distributed
file system library supports symbolic links to remote files; the
syntax for remote files is some sort of "host:pathname" syntax.
Symbolic links to directories may be a pain, but it's a pain we'll
have to live with unless we forbid symbolic links completely.
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
guy@sun.comrwhite@nu3b2.UUCP (Robert C. White Jr.) (06/16/87)
I have been reading these articles since I joined USENET [some 1.5 weeks ago] I feel that I am fairly well informed but... What is a "symbolic" link? Is is different from a regular link? am I crazy? :-) Did I miss something important in my education? 8-) Someone please respond or mail me an explination. Thanks. Robert.
jfh@killer.UUCP (John Haugh) (06/16/87)
I don't use BSD-Unix, so I never know what I am talking about. You can stop reading now if you want to. I spent some time using Ultrix on a uVax-II and sort of liked it. The biggest problem I had was understanding what I got if I stat(2)ed a symbolic link. My USG-Unix brain says I should get a stat structure saying I found a symbolic link. But I don't seem to believe this is the way it works. Please, send some manual pages to this poor degenerate System V user. I need the confusion at this time in my life. - John. (jfh@killer.UUCP) (Down and out in the Big D) Disclaimer: No disclaimer. Whatcha gonna do, sue me?
guy@gorodish.UUCP (06/16/87)
> What is a "symbolic" link? It is a special kind of "file". The "contents" of the file are a string representing a pathname; most references to the file are converted by the system into references to the file specified by that pathname. > Is is different from a regular link? Yes. A regular link, in effect, is a map between a file name and a particular inode on the file system where the directory containing that link resides; a symbolic link is a map between a file name and whatever file happens to have another file name. For one thing, this means that symbolic links can be made to files on other file systems. For another, if you have two hard links to a file, and do an "mv" to replace one of those links with a link to a different inode, the second hard link will still refer to the original inode, and thus the original file. If you have a symbolic link to a file, after the "mv" the symbolic link will refer to the new file. In addition, you can make symbolic links to directories; only the super-user can make hard links to directories in most UNIX systems, and even that is very much NOT recommended. (The main reason it's supported at all is that in many UNIX systems, the only way to rename a file is to make a second hard link to it with the new name, and get rid of the hard link with the old name.) > Did I miss something important in my education? 8-) Well, the more you know about various UNIX implementations, the better; for one thing, it means you can sometimes avoid reinventing the wheel (or, worse, the *square* wheel). Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
rbj@icst-cmr.arpa (Root Boy Jim) (06/17/87)
In article <7724@brl-adm.ARPA> rbj@icst-cmr.arpa writes: >I think the key word here is "the". The kernel implements symbolic >links as you describe below; the csh maintains $cwd symbolicly. If you >do `cd /foo/bar' where /foo/bar -> /whiz/bang followed by `cd ..', >$cwd gives /foo while pwd gives /whiz. Thus csh is interpreting `..' >to mean `back' while the kernel takes it to mean `up'. So the question is: where should you end up?. Ignore for a moment the problem of where this special treatment of ".." belongs (shell, kernel, etc). The question is: if a user does a "cd /foo/bar" and then "cd ..", is it reasonable to expect to be in /foo whether /foo/bar is a symbolic link or not?. Yes, it is reasonable. Is it the best thing to do? Maybe. If you write a shell that does this, I won't barf. It would be nice if the behavior was controlled by a switch (some have done this). One could even use the notation `...' to mean "*rindex(cwd,'/') = 0;". Strrchr for TPC folks. >In fact, symbolic links are no worse than when root makes links >between directories. The possibility exists for loops The kernel will detect a loop with symbolic links when the count of symbolic links being encountered by namei() while translating a filename exceeds some constant (8, I think). I know that, and it's irrelevant. But it won't detect hard link loops, except by length of pathname limits. One of my points was this: cd /usr; mkdir a; mkdir b; ln -s /usr/a b/a; ln -s /usr/b a/b cd a; cd b; cd a cd ..; cd ..; cd .. In a case like this, the shell would have no problem, but the kernel would have to remember the entire history of how you got here. After line 3 csh would think we were in /usr/a/b/a, which is really /usr/a. The first exit out of a takes us to /usr/b, but the second takes us to /usr. > What would be the best semantics for ..? > >Exactly what they are now as far as the kernel is concerned. The kernel has no history of pathnames. Your working directory is inode 347. In fact, maybe it should. Allow me to restate Korn's proposition as "THE IDEA OF A DISEMBODIED `WORKING DIRECTORY' IS A BOTCH" Why not just go all the way? Keep *both* pieces of info in the inode in core: where we are (inode 347), and how we got here. Keep the same semantics for `..' since our graphs will still look pretty much like trees, and make `...' be `where you came from'. Obviously, ... cannot be kept on disk, and the kernel would have to implement the semantics of `...'. Right now, it doesn't know about `.' and `..'. Symbolic links would *not* be resolved in the inode structure. The problem ("cd /foo/bar; cd ..") still remains, then. You could argue that the special treatment for ".." belongs in the shell, but then what about a program that does a chdir or the C preprocessor searching for "../x.h" ? We would really have to change all the programs that deal with filenames and put special code in them to deal with "..". This is clearly wrong. One should be careful when using links, hard or soft. I would add, however, that bombing out when `../x.h' cannot be found is better than finding another x.h in another directory. "Hey Ralph, I can't compile this!" "Yeah? Did you cd thru a symbolic link to the source directory?" "Yeah, I've been cd'ing all over the place. I better login again." This is clearly even worse. Use `#include ".../x.h"'. On second thought, DON'T! Or the anecdote I described becomes a nightmare! >what happens when you type `cd ..', I can see several alternatives. >Possibly the best is to not treat it specially. Why?. A user that does "cd /foo/bar" and then "cd .." expects to be in /foo. He/she doesn't know and DOESN'T NEED to know that /foo/bar is a symbolic link. Naive users don't even know what symbolic links are. Those last two statements contradict each other. It would be nice if one didn't have to know about symbolic links. However, if /foo/bar points to /qaz/wsx, then he needs to know! Besides, no one can remember what directory they're in anyway. That's why we have the pwd command, or have $cwd as part of our prompt. And the latter fails across symbolic links. >consider the case of loops, where after `descending' into the same >directorys a few times and realizing what happened, do you want to >retrace your steps in reverse, or go straight up as fast as possible. That is not me being quoted. I think it's Korn. The answer is, possibly either. So gimme both `..' and `...' please. Let the kernel deal with the loops. As I said before, after a number of symbolic links are encounteres, it gives up with an ELOOP error. Well, loops are pretty pathological in either case. Even without loops, the same problems exist. Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 Hello. Just walk along and try NOT to think about your INTESTINES being almost FORTY YARDS LONG!!
tim@ism780c.UUCP (06/17/87)
In article <7724@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes:
< It would be like Version 6, right? I think `cd ..' didn't work at
< the `root' of a mounted file system.
Correct, it didn't.
On System V before release 3, and on TS 1.0 ( and, I suspect, on
all other AT&T Unix systems ), the kernel did not actually check
for "..". Instead, it checked for inode == 2 and the second
character of the name being "." and the file being a directory.
This allowed some interesting things:
# umount /dev/dsk/usr.disk
# mkdir /usr/a.dir
# mount /dev/dsk/usr.disk /usr
# cd /usr
# ln .. a.dir
Now, if you do "cd .." from /usr, you end up in /, but if you
do "cd a.dir" ( which is a link to ".." ) from /usr, you end
up in the a.dir directory under /usr on the root file system.
--
Tim Smith "Well if you want to say yes, say yes
{seismo,sdcrdcf}!ism780c!tim And if you want to say no, say no
'Cause there's a million ways to go
You know that there are"rbj@icst-cmr.arpa (Root Boy Jim) (06/17/87)
>Symbolic links are mainly a facility to get around certain unix limitations >such as: you can only mount a file system at one mount point at a time (and >hence all the disk space has to be used in one file subtree). It allows >programs with hardcoded pathnames to traverse (one-way) and get to files >even when the sysops need to place the files elsewhere. >-Dave Lennert HP ihnp4!hplabs!hpda!davel This leads to wanting more versions of soft-links: "search order is: soft link only for write, soft link first and hard link second for read" and its 5000 nearly identical brethren. Hey, neat! Let's go to 32 bits for modes! Other rwxrwxrwx values :-) would mean `symbolic write link for owner', `symbolic read link :-) for group', `symbolic execute (or search) link for others', etc. :-) The extra sticky bit would determine whether `..' was `up' or back' :-) The concept of the soft link is a wart on the Unix file system. It is elegant, powerful, and valuable, but a wart none the less. It contravenes the important principle that ". and .. are the only circular links". This principle is an implicit assumption of much of the software on Unix systems and of most of the users. It is often used in ported source code (#include "../h/foo.h" as mentioned above). So is the concept of a hard link. "What, how come my file changed?" "Well, it's a link to this *other* file, and I changed *that* one, and ..." So is the concept of a mounted file system, for that limits hard links. Thus, I am lead to the conclusion that soft-links to directories should be avoided in places where .. is going to be used. It is too likely to cause problems that are hard to notice and diagnose. Caution is advised. The only system that I have access to that provides soft links specifies that soft links to a directory may only be done by the super-user. Too cautious. It would appear that other people have come to the same conclusion. (I presume that this is a standard restriction on all systems with soft links. If not, then perhaps it should be.) It is not. I will agree that there are some semantic areas of symlinks that have not been fully addressed. I would like to see an extensive paper written on all the options and choices made regarding symlinks. Some of these seem to be made on an ad hoc basis. Some programs know about them, some don't. What decisions were made and why? --------- .signature eater food --------- John Macdonald UUCP: {mnetor,utzoo} !spectrix!jmm internet:Sorry. We're in range, but we're in no domain. Disc-claimer: (noun) any hack's source directory (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688
snoopy@doghouse.gwd.tek.com (Snoopy) (06/18/87)
In article <912@rtech.UUCP> jas@rtech.UUCP (Jim Shankland) writes: >> "Everything is a file." >Repeating that everything is a file, whether or not it is true, is not >a useful exercise. A terminal is a file, but I can't seek on it; >a (vanilla) pipe is a file, but I can neither seek on it nor name it; >/etc/passwd is a file, but I can't mount it; the swap partition is a file, >but I can't put it into cbreak mode; and so on. There is a difference between saying "You can't because it is impossible" and saying "You can't because I won't let you." One of the big wins in Unix is that it doesn't put up artificial restrictions. >>Yes, the "cd .." and "pwd" stuff can get a bit confusing.... How about >>adding options to cd and pwd (and whatever) to specify going up rather >>than back? [yeah, I know, Yet Another Option :-( ] Sometimes it would >>be handy to get pwd to tell you both paths. >In general, having turned the name space into a dag (graphs with cycles, >not being well-formed name spaces, are not considered), there may be more >than two ways "up;" "pwd" could output arbitrarily many paths. I'm think of having the shell remember how you got somewhere, and having a built-in pwd tell you how you got there (using the symlink names), while "pwd -L" (or "/bin/pwd" ?) would give the "real" path. There could be many possible paths through symbolic links to get there, but you only got there one way, so there is only one symbolic link path to print out. Guy Harris writes: | Disallowing symbolic links to nonexistent files - or, in fact, doing | ANY checking of the contents of the symbolic link - would tick off a | lot of people. For example, I think the ISIS user-level distributed | file system library supports symbolic links to remote files; the | syntax for remote files is some sort of "host:pathname" syntax. I don't know about ISIS, but with DFS I can say ln -s //machine/usr/foo/src/bar/RCS RCS make bar and *presto*, everything works. Very nice! | Symbolic links to directories may be a pain, but it's a pain we'll | have to live with unless we forbid symbolic links completely. Or until we figure out how to deal with them properly. A surprising number of utilities need to know about the existance of symlinks. A lot of the problems with symlinks is that various utilities don't support them properly. For example, what does your ls do when you say "ls -lFL" for a symlink pointing at non-existant file? Mine does: ?????????? ? ???????? ? ??? ? ??:?? foo <- bar@? What else can it do? The info it wants to print isn't there. Chris Torek writes: (from the /dev/stdin discussion) } One of the wonderful things about Unix is its simple naming scheme. } Everything is a file. Want to see a file? `cat foo'. Want to } see a directory? `cat .'. Want to see what is on a tape? `cat } /dev/tape/rdefault' [*]. In V8 processes became files, through } /proc. This is the right way to go. Hey, does this mean I could have a symlink to a process?? (If I had v8) Cosmic! Snoopy Unnecessary restrictions? tektronix!doghouse.gwd!snoopy Just say NO! snoopy@doghouse.gwd.tek.com
zink@bunker.UUCP (David Zink) (06/19/87)
I'm So confused. What's wrong about more than eight symbolic loops? What's the difference between : mkdir foo ln -s `pwd` foo/foo followed by reference to a pathname with infinite foo/'s in it as compared with a pathname with infinite ../'s in it? What's the point of outlawing some loops and not others? And what's more important, why invalidate otherwise valid pathnames? I'm serious, Isn't the maximum pathname length a firm enough limit on looping? ELOOP is just a lie, after all, based on a stupid assumption. Symbolic links have to break code with ..'s in it because half will mean up and half will mean back; why change the meaning of .. to break one half when we can just leave the meaning the same and still break half. (or is it just the ATT crowd saying lets do the ATT botch that's not like the UCB botch?) David Zink.
kre@munnari.UUCP (06/20/87)
In article <2211@bunker.UUCP>, zink@bunker.UUCP (David Zink) writes: > What's wrong about more than eight symbolic loops? There's nothing magis about 8, pick any number you like, (it should probably be a config parameter), however there has to be a limit. > Isn't the maximum pathname length a firm enough limit on looping? No, symbolic links aren't expanded into the pathname, to make a long string that is then looked up normally. Rather, the contents of the symlink simply replace the component that is the name of the symlink. So, consider ln -s a a then open("a", 0); if there was no limit, the kernel would iterate on the symlink forever, as the name length is continually 1, after every time he symlink replaces the component. Of course, the kernel could trivially catch this degenerate case, but expecting it to catch ln -s a z ln -s b a ln -s c b ... ln -s z y is expecting a little too much. On the general question of symbolic links .. I have changed my opinion on them recently, not their usefulness, but on how they should be seen to the user. I used to believe that a symlink should appear as a link in as many ways possible (so much that I have always changed the sense of the 'L' flag in "ls" so that the default is to show the file linked to, rather that the symlink itself). However, I'm not of the opinion that this is wrong. Symlinks should be regarded as real objects, and not as poor cousins. I'm no longer going to fool with "ls". Most of the "problems" with symlinks seem to be because we seem to want to forget that symlinks exists, and just pretend that they are directories (to the extent of having ".." reverse a symlink, a totally absurd idea). Much better would be to simply educate users, let them see symlinks as real objects in the filesystem. At the minute, I have to know that 'foo' is a directory before I attempt "cd foo", I'm expected to remember that (or discover it). Expecting users to know that 'foo' can be either a directory or a symlink, and that which it is causes different effects, isn't too much to ask I think. Its time for symlinks to come out of the closet. Stand up and be counted! This does mean implementing sensible semantics for most of the sys calls when applied to symlinks, chmod should work (rather than passing through), and the modes should mean things. "r" would let you see the contents of the symlink, "w" allow you to change it, and "x" to access its value in a path lookup. I have ideas for the set[ug]id bits, and I'm sure a meaning for sticky will come to me! I would like to discard "readlink" and replace it with "read", probably with an extra mode to open to say "don't follow". Then "write" could be used to change the value of a symlink ("symlink" could be replaced by "mknod, write" but I think that's going a bit far). Rename, unlink, and chown already work properly. stat and lstat are OK. Access is a tricky one, an extra "don't follow" mode bit is probably needed there. "Link" is hard, both meanings make sense, and there's no flags word with convenient unused bits in it. This might necessitate a new syscall (ala stat/lstat which was in the same position). The sys calls that take a path for some odd purpose (acct, mount, etc) should just operate as they do now. kre
ekrell@hector.UUCP (06/21/87)
In article <2211@bunker.UUCP> zink@bunker.UUCP (David Zink) writes: >I'm So confused. What's wrong about more than eight symbolic loops? >What's the difference between : >mkdir foo >ln -s `pwd` foo/foo >followed by reference to a pathname with infinite foo/'s in it as compared >with a pathname with infinite ../'s in it? How can you have an infinite number of ".."s in a filename unless you encounter a loop somewhere (either symbolic or hard link)?. >What's the point of outlawing some loops and not others? And what's more >important, why invalidate otherwise valid pathnames? All loops are invalidated (ie, catched). Someone decided that 8 was large enough for the maximum number of symbolic links encountered during the expansion of a particular pathname. >(or is it just the ATT crowd saying lets do the ATT botch that's not like the >UCB botch?) It isn't an ATT vs BSD battle. The point is that some people considered the semantics of symbolic links as implemented in BSD to be a botch. If symbolic links could be added to System V, should they be broken too (just to keep BSD compatibility), or should they be done the right way? Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
jerryp@tektools.TEK.COM (Milan Moncilovich) (06/21/87)
In article <2075@emory.UUCP> arnold@emory.UUCP (Arnold D. Robbins) writes: > To change the subject slightly; it has always struck me as wierd > that the mode bits on a symbolic link have absolutely no relevance to > anything; if a symlink is created with mode 000, you can still do > a readlink on it! The problem is, I can't come up with decent semantics > for the mode bits. (I.E. I think the current semantics are wrong, but > I can't come up with anything better.) How does the Ninth Edition > handle it? Comments, anyone? In article <1715@munnari.oz> kre@munnari.oz (Robert Elz) writes: >This does mean implementing sensible semantics for most of the sys >calls when applied to symlinks, chmod should work (rather than passing >through), and the modes should mean things. "r" would let you see >the contents of the symlink, "w" allow you to change it, and "x" to >access its value in a path lookup. Can someone explain why symlinks were set up this way (modes ignored)? It's always been a hassle for me, and I don't see much benefit from the behavior. Fr'instance, I like to do a "chmod 311" on my binaries so that, when I do grep blat * in a directory full of shell scripts and binaries, "grep" won't print garbage when it finds a match for "blat" in the middle of a binary file. If I have a symlink pointing to a binary, and the binary doesn't belong to me, a "chmod 311" on the symlink complains "chmod: <link-name>: Not owner". Why were symlinks set up this way, and why shouldn't they be fixed as Robert Elz suggests? --Jerry Peek uucp-style: {allegra,decvax,hplabs,ihnp4,ucbvax}!tektronix!tektools!jerryp Domain-style: jerryp@tektools.TEK.COM I don't speak for Tektronix or its employees (or even for myself, at 6 AM).
geoff@wrs.UUCP (Geoff Espin) (06/22/87)
In article <679@nu3b2.UUCP> you write: > >I have been reading these articles since I joined USENET [some 1.5 weeks >ago] I feel that I am fairly well informed but... > >What is a "symbolic" link? >Is is different from a regular link? >am I crazy? :-) >Did I miss something important in my education? 8-) > >Someone please respond or mail me an explination. > Thanks. > >Robert. Sorry to FLAME you but... 1) You posted to comp.unix.wizards which is supposedly for "advanced" questions [1]. You should at least have had the sense that your question was of a basic nature, i.e. maybe fit for comp.unix.questions. You are "fairly well informed" about what? AIDS? Aren't we all by now? 2) The "man" command can be useful. It's actually faster than sending junk queries over the net -- though the output is rather predictable. :-( Presuming that you're not on some relic UNIX system without symbolic links, try: man ln 3) Your spelling is atrocious, especially the following mapped files discussion. Please run your letters through "spell", or better still "| head -0" :-) --- [1] Here's to calling the kettle black, but I couldn't mail to nu3b2? Geoff
dmr@alice.UUCP (06/22/87)
Symbolic links are indeed for the most part a botch, because they disturb the near tree shape that convention gives to the Unix file system. Trees are easily understood both by people and by programs; more complicated shapes are not. Already, even in the traditional file system, the existence of shared leaves (hard links) causes a certain amount of confusion. With symbolic links the situation is considerably messier because the shape is that of a general graph (not a DAG). For the most part, the BSD and V8 conventions for dealing with symbolic links are well-chosen, but there has still been a significant increase in complexity; this is indicated, for example, by continual questions about which operations should follow links, and which should not. Even if all the questions are given a satisfactory answer, their existence suggests that something is wrong. Nevertheless, symbolic links are sometimes useful, mainly because the attractive and well-controlled tree-shaped file system does not always map well onto real disks or remote machines. Unix makes it easy to move a node in the file system tree and its descendants to a separate disk partition or perhaps to another machine, but not to put several such nodes into one partition unless their parent and all their siblings are there as well. If we are to have symbolic links, I would, therefore, like to make them as obvious as possible instead of as transparent as possible, because they cannot be transparent; they introduce a new and not easily comprehended structure. That is, I would like people to be able to think of the file system as truly a tree (albeit with readily understood annotations like `..') and to have any symbolic links understandable as abbreviations or macros used in naming the actual structure. Thus it disturbs me not at all that our pwd gives one's actual location in the tree. In particular, Korn's proposal to reinterpret the meaning of .. depending on the history of the process seems unfortunate, because `..' no longer has any meaning with repect to the hierarchy; indeed, there no longer is any hierarchy. (Thoughts about `...' seem only to make matters worse). Another way to put this is that the proposal promises more than it can possibly deliver; it does make certain local operations like `pwd; cd symlink; pwd' behave more as they would if the graph were a tree, at the cost of concealing the global structure. The simulation of the tree has further peculiarities: `ls symlink/..' and `cd symlink; ls ..' still behave differently. The real problem is the symbolic links themselves, but I think the proposal exacerbates it rather than relieves it. Dennis Ritchie
beattie@netxcom.UUCP (Brian Beattie) (06/22/87)
Keywords: In article <2676@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: >If symbolic links could be added to System V, should they be broken too >(just to keep BSD compatibility), or should they be done the right way? > > Eduardo Krell AT&T Bell Laboratories, Murray Hill > > {ihnp4,seismo,ucbvax}!ulysses!ekrell Would you care to discuss what is in your view the right way? Thanx -- ----------------------------------------------------------------------- Brian Beattie | Phone: (703)749-2365 NetExpress Communications, Inc. | uucp: seismo!sundc!netxcom!beattie 1953 Gallows Road, Suite 300 | Vienna,VA 22180 |
rbj@icst-cmr.arpa (Root Boy Jim) (06/23/87)
Well, I seem to have found myself a subject I can sink my teeth into! In article <2211@bunker.UUCP>, zink@bunker.UUCP (David Zink) writes: > What's wrong about more than eight symbolic loops? Good explanation [deleted]. Most of the "problems" with symlinks seem to be because we seem to want to forget that symlinks exists, and just pretend that they are directories (to the extent of having ".." reverse a symlink, a totally absurd idea). Unfortunately, too many people seem to agree with you. Much better would be to simply educate users, let them see symlinks as real objects in the filesystem. At the minute, I have to know that 'foo' is a directory before I attempt "cd foo", I'm expected to remember that (or discover it). Expecting users to know that 'foo' can be either a directory or a symlink, and that which it is causes different effects, isn't too much to ask I think. Another good point. Let us be wizards. Its time for symlinks to come out of the closet. Stand up and be counted! This does mean implementing sensible semantics for most of the sys calls when applied to symlinks, chmod should work (rather than passing through), and the modes should mean things. "r" would let you see the contents of the symlink, "w" allow you to change it, and "x" to access its value in a path lookup. I have ideas for the set[ug]id Yes. I guess the originators figured that the target files modes would do the real duty. But if so, why make ch{own,grp} affect the link? bits, and I'm sure a meaning for sticky will come to me! I would like For the TPC folks, the sticky bit would let subsequent `..' mean `back' rather than up. to discard "readlink" and replace it with "read", probably with an extra mode to open to say "don't follow". Then "write" could be used to change the value of a symlink ("symlink" could be replaced by "mknod, write" but I think that's going a bit far). Rename, unlink, Careful, you might break code! and chown already work properly. stat and lstat are OK. Access is a tricky one, an extra "don't follow" mode bit is probably needed there. "Link" is hard, both meanings make sense, and there's no flags word with convenient unused bits in it. This might necessitate a new syscall (ala stat/lstat which was in the same position). The sys calls that take a path for some odd purpose (acct, mount, etc) should just operate as they do now. One thing I *would* like to see is to make `ls -F' report symlinks that resolved to directorys marked with a trailing *back*slash, rather than just a slash. That way we could tell the difference. kre (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688
ekrell@hector.UUCP (06/23/87)
In article <209@netxcom.UUCP> beattie@netxcom.UUCP (Brian Beattie) writes: >Would you care to discuss what is in your view the right way? In this case, the "right way" would be one where "cd foo; cd .." does what a naive user expects it to do (which is done by the way at mount points and remote file system mount points anyway). To be really perfect, though, it shouldn't break any current code. These two are conflicting goals and the question is whether we should leave them broken the way they are (the argument here being compatibility and such) or try to change their semantics. I don't know the answer but I certainly like the idea of "cd a/b; cd .." being equivalent to "cd a" whether "a" is a mount point, RFS mount point or a symbolic link. Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
steve@nuchat.UUCP (Steve Nuchia) (06/23/87)
(Isn't is about time we changed the subject line? :-)
In my experince, which is oriented towards software engineering
in general and portable commerical software in particular, links
to directories are about a 70% solution - they are helpful but
aren't _exactly_ the right thing.
Let me describe what I've whished for, and show how it could
be useful in other contexts.
Instead of allowing directories to be links to another directory,
have an object with the superficial semantics of a directory but
implementing a "copy-on-write" window onto a search path of other
directories, perhaps chained to arbitrary depth. I'm not concerned
with implementation directly here; please allow me to speak (?)
a little metaphorically.
As a version control mechanism the application is obvious: each version
is a "copy-on-write" image directory, with files carried through from
previous versions visible but not modifiable. A similar scheme was
described in the Portland usenix proceedings under the title
"A Rich Man's SCCS" or something like that. The author modified
a large number of standard utilites, notably cp and the editor,
to achieve essentially the semantics I describe using standard
hard links.
In environments requiring customized bin direcories, notably
heterogenous NFS nets and "universe" implementations, the standard
practice is to have a directory for each requirement, with each
NFS host symlinking or mounting or whatever the right one. In
universe implementations it is customary to have the symlink
mechanism switch off of the universe flag. The shortcoming in
both cases is that files held in common between the two require
special maintenance (shell scripts? ...). My directories would
simply have the shared stuff in the right place and then different
folks would search for their different strokes by following their
appropriate links. (A similar requirement was brought up not
too long ago in reference to the netnews software: In a NFS
environment the "libdir" need sto be "purified" of binary files;
a perfect application of this concept).
I have occasionally had to build a directory with a link to each
file in another directory and then make a few small changes in
the set of files: a deletion here and an addition there. Situations
come up often where it would be nice to be able to set up a
directory "just like" another "except for ...". Sure, there are
(almost) always workarounds, but you recognize what I'm talking
about, don't you?
Then there's rsh bin directories (Restricted, not Remote SHell),
various reasons for a writable copy of a read-only directory,
etc. In fact, wouldn't it be nice if ~/bin was an image-link
to /bin:/usr/bin? Sure, we've got mechanisms for doing the same
thing, but it would be a cleaner world without execvp(2). :-)
Implementation shouldn't be a huge challenge, and I'd use this
a lot more frequently than links to directories. If I wanted
the other directory I'd just use it: Except for crossing mount
points, symlinks to directories are of precious little use to
me. Image links are a horse of a different color, And I'd like
to hear from those in whom my remarks strike a responsive chord.
The semantics of the proposed facility need to be nailed down,
and an existance proof of implementability need to be sketched.
(needless to say, the implementation scheme will define the
semantics as usual, but we can dream, right? :-)).
Flames to /dev/null: I've thought about this a lot and would like
the courtesy of a well thought out refutation. 1/2*:-)
It is my hope that this will serve as a fulcrum to turn
the discussion away from all the things that _are_ wrong
with links to direcories and towards a better way to do
their job. I could probably do a better job on the presentation
if I didn't try to write this late at night, but its now or never...
Thank you for your attention.
Steve Nuchia (713) 334 6720 voice
{housun,{soma,academ}!uhnix1}!nuchat!steve
(713) 334 1204 2400N81 "trouble" sends anonymous mail to me.gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/23/87)
In article <2680@ulysses.homer.nj.att.com> ekrell@ulysses (Eduardo Krell) writes: >I don't know the answer but I certainly like the idea of "cd a/b; cd .." >being equivalent to "cd a" whether "a" is a mount point, RFS mount point >or a symbolic link. It seems to me we're gradually wobbling our way towards the idea that the "current working directory" is really just a "prefix" to be used for relative path resolution. This approach is taken by some OSes (Apple ProDOS being one I'm quite familiar with) and it seems to work fine. Indeed, it generalizes nicely so that one can have a handful of current prefixes simultaneously available, e.g. one for libraries, one for commands, etc. Of course UNIX implementations of the "prefix" would remarkably resemble what they're doing already for the cwd. (One doesn't have to ACTUALLY prepend a prefix text string then look up all inodes in the path starting at the root every time one opens an object!) With the prefix approach, the natural meaning of "cd" is "set new prefix", and "cd .." most naturally would mean "trim off the most local pathname component from the current prefix". I recommend that we move UNIX toward prefixes as a better naming concept than "working directory".
mkhaw@teknowledge-vaxc.ARPA (Michael Khaw) (06/24/87)
In article <1008@killer.UUCP> jfh@killer.UUCP (John Haugh) writes: >biggest problem I had was understanding what I got if I stat(2)ed a symbolic >link. My USG-Unix brain says I should get a stat structure saying I found >a symbolic link. But I don't seem to believe this is the way it works. > "man 2 stat" on my Ultrix system says that - stat(2) gets you information on the file - lstat(2) gets you information about the symlink if the file is a symlink, otherwise it's just like stat() so stat() doesn't let you know if you gave it a symlink, because it returns information about the target of the symlink. Mike Khaw -- internet: mkhaw@teknowledge-vaxc.arpa usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
redden@ttidca.TTI.COM (John Redden) (06/24/87)
I mentioned this as a proposal to our systems group and it generated a bit controversy. We run a number of flavors of Unix at TTI. The most popular are BSD based thus symbolic links (as opposed to hard links) are used often in our work. Typically we use symbolic links to create a view (or schema if you will) of one of our file systems to conform to another organizations (equally valid) view of a file system. This is particularly useful in a *heavily* cross mounted NFS environment. Very early in the game we discovered the semantic anomally of cd .. after a cd to a directory that was an object of a symbolic link. This is not a great problem as long as the semantic behavior is understood. And actually its easy to create an alternate "cd .." to the subject directory of the symbolic link. It would be nice to have a consistant syntax for cd: cd .. takes you the real parent (as it currently does) cd ... takes you to the first symbolic link cd .... takes you to the second symbolic link cd ..[.]*. takes you to the ith symbolic link One bad side effect (no considering implementation problems) would be that ... and the like would become illegal file names. Comments? These are solely my opinions and not the people whom I work with.
elein@pnn.UUCP (Elein Mustain) (06/25/87)
In article <189@wrs.UUCP>, geoff@wrs.UUCP (Geoff Espin) writes: > In article <679@nu3b2.UUCP> you write: > > > >What is a "symbolic" link? > > > >Robert. > > I had planned to save the net from this flame but you didn't include your mail path. Use the 'n' key if you don't want to hear about manners. FLAME: Geoff, people like you give wizards a bad name. I have found this group to be extremely polite and useful. There will always be misdirected queries from people. The most helpful way to redirect them is to mail them an answer and suggest that they try the comp.unix.questions group. > 1) You posted to comp.unix.wizards which is supposedly for "advanced" > questions [1]. You should at least have had the sense that your > question was of a basic nature, i.e. maybe fit for comp.unix.questions. > You are "fairly well informed" about what? AIDS? Aren't we all by now? > In this case, since the discussion was here, the question was not out of order. The analogy about AIDS is completely inappropriate. > 2) The "man" command can be useful. It's actually faster than sending > junk queries over the net -- though the output is rather predictable. :-( > Presuming that you're not on some relic UNIX system without symbolic > links, try: man ln > A gentle suggestion always works better. Unless you are so insecure that you must assert your shakey superiority. > 3) Your spelling is atrocious, especially the following mapped files > discussion. Please run your letters through "spell", > or better still "| head -0" :-) I seem to remember a part in the net etiquette document (DID YOU EVER READ IT?) about spelling flames. I direct you to read the new user net documents. Since you feel qualified to answer questions here I can't understand why you missed it. Or are procedures and proper posting only applicable to people you think are neophytes. > [1] Here's to calling the kettle black, but I couldn't mail to nu3b2? We could do without this ancient racist cliche. > Geoff Now back to our regularly scheduled group discussions. --Elein -- ======== A. Elein Mustain UUCP:{stcvax,isis,ihnp4}!onecom!pnn!elein TelWatch, Inc. @ Oakland,CA VOICE:(415)654-7435 My opinions are my own and I reserve the right to change my mind.
roy@phri.UUCP (Roy Smith) (06/25/87)
In <6018@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > It seems to me we're gradually wobbling our way towards the idea that > the "current working directory" is really just a "prefix" to be used > for relative path resolution. [...] With the prefix approach, the natural > meaning of "cd" is "set new prefix" [...] Indeed, this is exactly the way I explain "cd" to people just learning Unix. I find the approach to be simple and intuitive, and havn't yet run into anyplace where the "set prefix" abstraction has caused any confusion. Of course, most of my users just want to get their work done and don't care about the details of stat(2) and such. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
malcolm@spar.SPAR.SLB.COM (Malcolm Slaney) (06/25/87)
In article <6018@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn) writes: >It seems to me we're gradually wobbling our way towards the idea that >the "current working directory" is really just a "prefix" to be used >for relative path resolution. This approach is taken by some OSes >(Apple ProDOS being one I'm quite familiar with) and it seems to work >fine. Indeed, it generalizes nicely so that one can have a handful of >current prefixes simultaneously available, e.g. one for libraries, one >for commands, etc. > In effect Symbolics machines have taken this concept to extreme and I think it is a lose. Just about every user operation has a different concept of the current directory and I have yet to figure out their rhyme or reason. In some case, like editor buffers, it is pretty obvious but in other cases it isn't. For example the "copy file" command has a default directory which generally is identical to the last directory used. I'm sure if I did a bit of investigation I could figure it out its exact behaviour but that really shouldn't be necessary. At least Symbolics does show you the current default directory/pathname whenever you have to enter something. Malcolm
zink@bunker.UUCP (David Zink) (06/25/87)
> In article <2211@bunker.UUCP>, zink@bunker.UUCP (David Zink) writes: > > What's wrong about more than eight symbolic loops? I meant links! eight symbolic links! And thanx all who resp'd as I had never run into ln -s a a before, but I still don't understand why after ln -s a b ln -s b c ln -s c d ln -s d e ln -s e f ln -s f g ln -s g h ln -s h i , echo > i should fail? As I stumble through the code of various applications and operating systems I am continually appalled by the number of hard-coded constants: # of file descriptors, # of signals, # of characters in a filename or path. As unix matures it tends to slowly expand these numbers, and probably eventually make them indefinite. Unfortunately what usually happens is that the upper bound is what some person or group considered the largest sensible number. Why is it that at this late date people are still coding itty bitty constants like 8 into the kernal? I guess that my major complaint is that ELOOP purports to mean LOOP but really means EIGHT.
mkhaw@teknowledge-vaxc.ARPA (Michael Khaw) (06/26/87)
In article <876@ttidca.TTI.COM> redden@ttidca.UUCP (John Redden) writes:
->It would be nice to have a consistant syntax for cd:
->
->cd .. takes you the real parent (as it currently does)
->cd ... takes you to the first symbolic link
->cd .... takes you to the second symbolic link
->
->cd ..[.]*. takes you to the ith symbolic link
->
->One bad side effect (no considering implementation problems) would be
->that ... and the like would become illegal file names.
->
->Comments?
What about all the shell scripts that look for ".??*" expecting not to clobber
"." and ".."? They are for sure going to clobber "..." etc.
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303mouse@mcgill-vision.UUCP (der Mouse) (06/26/87)
In article <8738@tekecs.TEK.COM>, snoopy@doghouse.gwd.tek.com (Snoopy) writes: > There is a difference between saying "You can't because it is > impossible" and saying "You can't because I won't let you." One of > the big wins in Unix is that it doesn't put up artificial > restrictions. Well put. > [...] what does your ls do when you say "ls -lFL" for a symlink > pointing at non-existant file? Ours ignores the -L option, that is, it lists the symlink rather than the file it points to. > Chris Torek writes: (from the /dev/stdin discussion) >> One of the wonderful things about Unix is its simple naming scheme. >> [...] In V8 processes became files, through /proc. This is the >> right way to go. > Hey, does this mean I could have a symlink to a process?? > (If I had v8) Cosmic! Hey, does this mean that fork() is just a special case of mknod()? exit() just a special case of unlink()? Yow! Are we having FUN yet? der Mouse (mouse@mcgill-vision.uucp)
zink@bunker.UUCP (David Zink) (06/26/87)
In article <6018@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
]It seems to me we're gradually wobbling our way towards the idea that
]the "current working directory" is really just a "prefix" to be used
]for relative path resolution. This approach is taken by some OSes
](Apple ProDOS being one I'm quite familiar with) and it seems to work
]fine. Indeed, it generalizes nicely so that one can have a handful of
]current prefixes simultaneously available, e.g. one for libraries, one
]for commands, etc.
]
]Of course UNIX implementations of the "prefix" would remarkably
!resemble what they're doing already for the cwd. (One doesn't have
!to ACTUALLY prepend a prefix text string then look up all inodes in
!the path starting at the root every time one opens an object!)
]
]With the prefix approach, the natural meaning of "cd" is "set new
]prefix", and "cd .." most naturally would mean "trim off the most
]local pathname component from the current prefix".
]
]I recommend that we move UNIX toward prefixes as a better naming
]concept than "working directory".
Yay for Apple ProDOS MSDOS etc. You're right ! we should change UN*X to
work more like those beautiful OS'es. And when you type
cd /usr/JO
and root types
mv /usr/JO /usr/JMO
and you type
cd .
and The prefix /usr/JO/ is attached to it to make /usr/JO/. and the shell says
'.' NOT FOUND.
you're going to be so glad you got UN*X to work like a toy manufacturers
single-user operating system.
Of course the idea of prefixes for commands is $PATH that for libraries is
fixed at /usr/lib but since all unix people except wizards use makefiles
it may not be all that useful. Besides, following usual eunuch tradition
each different program would have it's own environment variable it would use
for this.
As far as cd .. goes, you can't usually unmount the filesystem containing a
directory which someone has open, say as cwd; however imagine
mount /dev/hd7 /mnt1
mkdir /mnt1/lice /mooseteeth
ln -s /mooseteeth /mnt1/lice/pointy
cd /mnt1/lice/pointy
umount /dev/hd7
cd ..
Nuff said?john@xanth.UUCP (John Owens) (06/26/87)
In article <6018@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > I recommend that we move UNIX toward prefixes as a better naming > concept than "working directory". And indeed, this is what VMS does, where the equivalent of "cd" is SET DEFAULT and it sets the default prefix for that process. If anyone tries to implement this, watch out for the misfeature that VMS has: you can SET DEFAULT successfully to any well-formed string, but you only find out whether or not the directory exists when you try to use it. Also, be aware that this will change the semantics of the following: User 1 User 2 cd /dir/one touch file mv /dir/one /dir/one.bak mkdir /dir/one /bin/pwd ls Currently, pwd will say "/dir/one.bak", and ls will show "file". If you implement directories as prefixes, pwd will say "/dir/one" and ls will show nothing. Which of these is most desirable is open to question.... -- John Owens Old Dominion University - Norfolk, Virginia, USA john@ODU.EDU old arpa: john%odu.edu@RELAY.CS.NET +1 804 440 4529 old uucp: {seismo,harvard,sun,hoptoad}!xanth!john
karl@haddock.UUCP (Karl Heuer) (06/26/87)
In article <2249@bunker.UUCP> zink@bunker.UUCP (David Zink) writes: >What's wrong about more than eight symbolic links? ... I still don't >understand why after [ a <- b <- ... <- h <- i ], "echo >i" should fail? It shouldn't, of course. And unless I'm missing something, it needn't. There exists a loop detection algorithm which uses O(log(N)) space and O(N) time (it doesn't detect the loop immediately, but it does stop before the third visit of any node). Why isn't this used? Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
karl@haddock.UUCP (Karl Heuer) (06/27/87)
In article <634@haddock.UUCP> karl@haddock.ISC.COM.UUCP (Karl Heuer) writes: >There exists a loop detection algorithm which uses O(log(N)) space and O(N) >time (it doesn't detect the loop immediately, but it does stop before the >third visit of any node). Why isn't this used [for ELOOP]? Alright folks, stop sending me mail on this -- yes, I know it can be done in O(1) space using the two-and-one algorithm, but that does not have the property I mentioned. For example, a -> b -> ... -> z -> z will require 75 link-traversals before the slower one catches up to the loop. I was thinking of the algorithm from HAKMEM, item 132. The extra O(log(N)) space is unimportant (32 words, since N < 2^32); the time savings is potentially more valuable. (Traversing a symlink is, I expect, an expensive operation.*) Of course, either algorithm is better than the current hopcount=8 kludge. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint *Hmm... Y'know, symlink target names are usually so short -- maybe they could be stored in the inode itself? When they're less than 40 chars, say?
matt@oddjob.UChicago.EDU (Older than any person of lesser age) (06/28/87)
I think everyone agrees that the question of the meaning of
symlink/.. is a user-interface question. Therefore I claim that
any special interpretation should be placed in the shell. For
myself, a csh user, I find that the following is just dandy:
alias up cd \$cwd:h
Then I can use it:
% cd /etc/yp
/etc/yp ~
% pwd
/usr/etc/yp
% up
% pwd
/etc
Hands off namei()!
________________________________________________________
Matt University matt@oddjob.uchicago.edu
Crawford of Chicago {astrovax,ihnp4}!oddjob!mattmouse@mcgill-vision.UUCP (der Mouse) (06/28/87)
In article <2680@ulysses.homer.nj.att.com>, ekrell@hector..UUCP (Eduardo Krell) writes: [ incidentally Eduardo, I suggest you get on your netnews admins to get rid of the extra . in that "..UUCP". ] > I don't know the answer [to the Right Way to handle symlinks] but I > certainly like the idea of "cd a/b; cd .." being equivalent to "cd a" > whether "a" is a mount point, RFS mount point or a symbolic link. It's not the symlinkness of a that matters but that of b. I agree, it's a nice idea, but it sounds to me more like a feature of cd than of symlinks. I've yet to hear a cohesive explanation of how symlinks would work that includes this feature as a side effect, that is, in a way that doesn't require special-casing cd. der Mouse (mouse@mcgill-vision.uucp)
allyn@sdcsvax.UCSD.EDU (Allyn Fratkin) (06/28/87)
In article <3855@oddjob.UChicago.EDU>, matt@oddjob.uchicago.edu (Matt Crawford) writes: > alias up cd \$cwd:h i use an alias almost like this, but mine looks like: alias .. 'cd /$cwd:h' the leading / before the $ is important. with your alias, typing "up" from a directory like /etc will move you to your home directory, not to / as would be expected. unfortunately, this doesn't help programs trying to open files with .. in the path. -- From the virtual mind of Allyn Fratkin allyn@sdcsvax.ucsd.edu or EMU Project {ucbvax, decvax, ihnp4} U.C. San Diego !sdcsvax!allyn
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/29/87)
In article <2250@bunker.UUCP> zink@bunker.UUCP (David Zink) writes: >Nuff said? Far too much for a message with zero information content. If you have a valid technical point to make, make it, but just trying to be cute is not appreciated.
zink@bunker.UUCP (David Zink) (06/29/87)
In article <6036@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: ]In article <2250@bunker.UUCP> zink@bunker.UUCP (David Zink) writes: ]>Nuff said? ] ]Far too much for a message with zero information content. ]If you have a valid technical point to make, make it, but ]just trying to be cute is not appreciated. Sorry, I usually have ~30 mins/week to read and respond to EMAIL news etc. and I get a little hot about things like people considering changing the kernal to support strange interpretation of '..'. The information content Intended was that because symlinks are used to cross filesystems '..'-as-last part-of-however-we-got-here can become meaningless. This cannot happen under the current implementation. Will this create new problems? I also expect that the correct Unix way to handle the problem would be to make it illegal to umount a device that has been cd'ed through. I have yet to see a well thought out proposal on the subject so I assume we are in the throw out possible objections before we have to start whining at ATTETC that they overlooked things. I also should have kindly pointed out that UNIX doesn't even have a current working directory concept, but a current working inode, which is nice because it helps the guru's to be able to patch things up without having to bring the system down. And I use silly examples instead of just describing ideas because they are less open to {mis,}interpretation. Just imagine typing them in and watch them perform. I agree I could have used better judgement in the choice of directory names, but I didn't. Too much said?
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (06/29/87)
In article <189@wrs.UUCP> geoff@wrs.UUCP (Geoff Espin) writes: |In article <679@nu3b2.UUCP> you write: |> |>I have been reading these articles since I joined USENET [some 1.5 weeks |>ago] I feel that I am fairly well informed but... |> |>What is a "symbolic" link? |>Is is different from a regular link? |>am I crazy? :-) |>Did I miss something important in my education? 8-) |> |>Someone please respond or mail me an explination. |> Thanks. |> |>Robert. | |Sorry to FLAME you but... | |1) You posted to comp.unix.wizards which is supposedly for "advanced" | questions [1]. You should at least have had the sense that your | question was of a basic nature, i.e. maybe fit for comp.unix.questions. | You are "fairly well informed" about what? AIDS? Aren't we all by now? Nice bit of gratuitous insult. If he doesn't know what it is, how can he know if it's advanced or not? This is where the discussion is, he assumed that this was where he should ask. | |2) The "man" command can be useful. It's actually faster than sending | junk queries over the net -- though the output is rather predictable. :-( | Presuming that you're not on some relic UNIX system without symbolic | links, try: man ln It may come as a vast suprize to you, but there are more people using SysV than BSD. There are also more copies of Xenix in use than any other implementation, and that doesn't even *include* the man pages! Of course the comment about relic operating systems is "real technical". You must be one of the people who tie up the net every few months with "my o/s is better than your o/s". | |3) Your spelling is atrocious, especially the following mapped files | discussion. Please run your letters through "spell", | or better still "| head -0" :-) Being such a hot shot, why don't you pipe your incoming mail through spell? You could use style and dict too, if you like. Why all the flames about a simple question? | |--- |[1] Here's to calling the kettle black, but I couldn't mail to nu3b2? | |Geoff I can't use you address, either. -- bill davidsen (wedu@ge-crd.arpa) {chinet | philabs | sesimo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (06/29/87)
In article <139@pnn.UUCP> elein@pnn.UUCP (Elein Mustain) writes: >In article <189@wrs.UUCP>, geoff@wrs.UUCP (Geoff Espin) writes: >> In article <679@nu3b2.UUCP> you write: >> > >> >What is a "symbolic" link? >> > >> >Robert. ... much flaming and flames of flaming deleted ... > >> [1] Here's to calling the kettle black, but I couldn't mail to nu3b2? >We could do without this ancient racist cliche. The original saying is "like the pot calling the kettle black". I don;t see a lot racist here. The saying originated when cooking was done over wood fires, and refers to a person with a bad habbit complaining about the same bad habbit in someone else. ... signatures deleted except mine ... -- bill davidsen (wedu@ge-crd.arpa) {chinet | philabs | sesimo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/30/87)
In article <2259@bunker.UUCP> zink@bunker.UUCP (David Zink) writes: >'..'-as-last part-of-however-we-got-here can become meaningless. This cannot >happen under the current implementation. Since I don't understand that logic (the current symlink implementation does not handle .. that way), let me paraphrase the argument. I think you're saying that if the underlying linkage structure (hard or soft) is rearranged, the "current working directory" concept acquires some warts (e.g. one's actual filesystem location could change with the cwd remaining fixed). This is true of ANY implementation; the only difference would be the particular nature of the warts. I have more than once found that "cd .." (old style) did not get me into an existing location. Fortunately this is a relatively unusual situation. The only reason that current implementations get away with keeping just the current inode (and device) is that that could serve as an abbreviation for the current path. With /proc, /n/face, and other oddball types of file system, it is rapidly becoming necessary to find some other way to record the "current working directory". A path prefix is certainly the simplest I can think of. (As I remarked earlier, it can also be generalized nicely to provide a NEW facility that UNIX hasn't had before. It also makes getcwd() a simple task.)
henry@utzoo.UUCP (Henry Spencer) (07/03/87)
> ... With /proc, /n/face, and other oddball types of file system, > it is rapidly becoming necessary to find some other way to record the > "current working directory"... V8 /proc preserves the semantics of a normal Unix directory setup *exactly*, unless I missed something subtle when I read the code. My impression is that /n/face does likewise. In both cases the directory hierarchy is actually a figment of the kernel's imagination, but it is a consistent figment with the same semantics as normal directories. -- Mars must wait -- we have un- Henry Spencer @ U of Toronto Zoology finished business on the Moon. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
throopw@xyzzy.UUCP (Wayne A. Throop) (07/06/87)
> mouse@mcgill-vision.UUCP (der Mouse) [refering to pathname segment a/b, and relating the case where a is a symlink to that where b is an NFS or RFS filesystem.] > It's not the symlinkness of a that matters but that of b. I agree, > it's a nice idea, but it sounds to me more like a feature of cd than of > symlinks. I've yet to hear a cohesive explanation of how symlinks > would work that includes this feature as a side effect, that is, in a > way that doesn't require special-casing cd. Ah! I was wondering just how to phrase my misgivings about comparing these two cases and insisting that they work in the same way, and here we have it. In the one case, the directory is special. In the other, something that *points* to the directory is special. It is not clear to me that the two cases ought to act analogously. Personally, I don't think symlinks are such a botch as folks make out. -- "... and every so often he gave a great screeching display, rushing about and slapping his sides." --- from "Marooned in Real Time" -- Wayne Throop <the-known-world>!mcnc!rti!xyzzy!throopw
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/13/87)
In article <241@nuchat.UUCP> steve@nuchat.UUCP (Steve Nuchia) writes: >... Image links are a horse of a different color, And I'd like >to hear from those in whom my remarks strike a responsive chord. One way to implement a similar facility is to support "union" mounting of directories (or more generally, named objects) on each other (as opposed to the "replacement" mounting we now have). This idea is not original with me, but I don't know if the originator wants to get involved in this discussion at this time. I won't explain how to implement this, since it's just straightforward exploitation of data structures. However, I do want to mention some of the things I've been thinking since I first heard this idea: Unioned directories could be used in several ways to accomplish useful things currently done via other approaches on conventional UNIX systems. For example, one could set up his "command directory" to contain the union of the desired real ones, replacing the PATH environment variable and making the shell's job simpler (since it would just open a command in a known place, rather than searching for it). As mentioned by Steve, this could also be used in a Yost-like SCCS replacement. "cc" could look in the user's "library directory" for all -l options. Many other similar uses come to mind. The order of precedence when two unioned directories contain entries having the same name would be determined by the order in which the directories were unioned. (In the PATH example, one would arrange for the directory that would normally be leftmost in the PATH to be the one with priority in the union.) There are uses for both union-with- highest-priority and union-with-lowest-priority, so both should be supported (I would do this at the system call level by using an extra argument analogous to the mount() syscall's R/W flag). The originator of this idea seemed to think that there was a natural choice to make here, but I think that the "natural" choice depends on the intended use and what is natural for setting up the equivalent of $PATH is not necessarily natural for other uses, e.g. pushing and popping environments. So far I've managed to identify the following union- mount functions that I think are necessary: Create a name with nothing associated with it (an empty union) Append an object to the union (with low precedence of its members) Prepend ditto (high precedence) Remove one object from the union "tail" (lowest precedence object) Remove one object from the "head" (highest precedence) Destroy the name/union (may require that it be empty to succeed) Optional but probably useful: Remove all objects from the union (leaving an empty union) Remove all objects but one from the head Ditto from the tail Report union tail object name (or other ID) Ditto head object name Ditto all unioned object names (this is difficult to design; perhaps it should just report the nth object from the head or tail.) Many of these functions, perhaps all, could be combined into a single interface. For example, head-relative might be a positive argument and tail-relative negative. That's enough for now. I'll let you guys think about this for a while. I think it's a marvelous idea if it can be made to work (and I think it can). However, the result would not be properly called "UNIX"..
ekrell@hector..UUCP (Eduardo Krell) (07/13/87)
In article <241@nuchat.UUCP> steve@nuchat.UUCP writes: > >Instead of allowing directories to be links to another directory, >have an object with the superficial semantics of a directory but >implementing a "copy-on-write" window onto a search path of other >directories, perhaps chained to arbitrary depth. I have already done exactly what you describe. We have an experimental unix kernel with this facility added. It's very similar to the viewpathing concept found in build and nmake (aka 4th generation make). Basically, one can create a "continuation" directory, which will be searched whenever a filename is being looked up and it's not found in the current directory. That continuation directory can have more continuation directories chained in a kind of linked list, and they are all searched in turn. If the same file exists in 2 or more of these directories, only the first one will ever be seen. File are always created in the first (original) directory. Only file lookups follow these continuation pointers. Eduardo Krell AT&T Bell Laboratories, Murray Hill {ihnp4,seismo,ucbvax}!ulysses!ekrell
tim@ism780c.UUCP (Tim Smith) (07/18/87)
This reminds me of something I wanted to do once. I wanted to have the
current directory be a union of two directories, say A and B. There would
be two ways you could set up searches to work:
1: A first, then B
2: A first for create or write access, B first otherwise
I never got around to trying it, though.
--
Tim Smith, Knowledgian {sdcrdcf,seismo}!ism780c!tim