mp (05/11/83)
There is a problem with "ln -s" on 4.1c (and presumably 4.1a). Suppose
/usr/src/usr.bin/cal.c exists, and /usr/mp is empty. If I cd to
/usr/src/usr.bin and do "ln -s cal.c /usr/mp/cal.c", then /usr/mp/cal.c
is a link to simply "cal.c". The fact that I was connected to
/usr/src/usr.bin when I made the link is not recorded. This means that
/usr/mp/cal.c points to itself.
The problem is that it's making a link to a relative pathname rather
than an absolute pathname. It could be worse, though - think of what
problems there would be if open("/usr/mp/cal.c", m) meant "open
whatever cal.c happens to be in the current working directory".
It's difficult to do the right thing here, unless ln has a way of
getting the absolute pathname of the user's connected directory at the
time the link is made.
Mark (genrad!mit-eddie!mp, eagle!mit-vax!mp)lepreau (05/11/83)
I believe that's a feature, not a bug. It allows symlinks between files
in the same dir tree to avoid long, unnecessary pathname lookups. E.g.,
% ls -l /usr/bin/foo
/usr/bin/foo -> bar
resolves to /usr/bin/bar but avoids accessing the /usr and /usr/bin
directories all over again in namei.
It does tend to be a gotcha, agreed. There is certainly a way for ln
to get the current dir abspath: getwd(3) == pwd. That could be added as
a flag to ln I suppose. But I've gotten used to doing
"ln -s $cwd/bar foo" (or `pwd`/bar, which is safer) if I need the full path,
which is most of the time, admittedly.
-Jay
lepreau@utah-cs, harpo!utah-cs!lepreau