How to make Symbolic Links

[Powermaster]

How would one go about making a Symbolic Link?

Thanks

[hazmat]

Here's an example. vi is in
/usr/bin/vi . You want a sym link to point to it from the same directory called vii. While in /usr/bin, you would type:

ln -s vi vii

You could specify absolute pathnames as well, so if you wanted a sym link called 'vi' in /usr/local/bin pointing to /usr/bin/vi , if you were in /usr/local/bin, you could type:

ln -s /usr/bin/vi vi


Does this make sense?

[Eckhart]

Yes, what 'ln' basically does is to write arg1 into a file called arg2 and flag the latter as a symbolic link.

Yet, by reading your post, I stumbled across some odds in MacOSX. I wanted to display the symbolic link as such, but not the file it is linked to. I know I was doing that somehow a whole while ago (not on MacOSX) and now I can't remember.

I tried a lot... I pentrated cat, od, file;
I messed with the "symlinks" option in tcsh. I tried to acces the file through its inode:
find ./ -inum 374355 -exec cat "{}" \;

But whatever I do, the system will always follow the symbolic link. HRRFF!

The same for directories, MacOSX will not allow to dump a directory to stdout using "od -c" for example. Whatever I do here, it keeps saying ".. is a directory".

The third question: Is any command line method known to you that flags a file as a symbolic link?

Thanks a lot!

[lurk]

Eckhart's description of what ln does is not actually correct. The way that a symbolic link is recorded in the file system is dependent on that filesystem. You are assuming an implementation which does not correspond to what is done in HFS+.

Now on my old AT&T 3B1 I could do what you describe but that would not work on many newer file systems because the representation of the directory is more complex. For instance some file systems directly record the symbolic link in the directory structure itself.

Finally, the assumption that there is actually a "directory listing file" does not hold for all file systems. The implementation you are describing in particular does not handle accessing long absolute paths well. Each path component has to be looked up in each directory along the way by a linear search which is basically a O(n*m) operation where n is the number of path components and m is 1/2 the average number of files in a directory. In comparison OS/@'s old HPFS file system used a balanced B-tree so such a search would take O(log(total files)) time (IIRC). The latter case has much better performance characteristics but therein directories are not explicitly stored, they are built on the fly from the individual entries. (Another neat thing if you have ever used zsh doing wild-inferiors was just as cheap as globbing. That is /foo/*.c was a fast as /**/foo.c which normally under unix requires a call to find to compute.)

-Eric

[Eckhart]

Originally posted by lurk
You are assuming an implementation which does not correspond to what is done in HFS+.

So what is it then? What I see on my box, when I create a symbolic link is an autonomous file (with its own inode) with the length of exactly the source path plus a certain flag.

For instance some file systems directly record the symbolic link in the directory structure itself.

Wow, I didn't know that. Which are these?

therein directories are not explicitly stored, they are built on the fly from the individual entries.

See, I'm really a rookie on filesystems, that is also new to me. But this is HPFS and not HFS+ is it?

(Another neat thing if you have ever used zsh doing wild-inferiors was just as cheap as globbing. That is /foo/*.c was a fast as /**/foo.c which normally under unix requires a call to find to compute.)

Same for tcsh and bash.

--
Is now anyone here, who can answer my actual questions? Thanks again!

[Arden]

The easiest way to create a symbolic link I know of is to download & install Cocktail, click on Files and the Links tab, and drag a file onto the button with the terminal alias on it.

[lurk]

Originally posted by Eckhart
So what is it then? What I see on my box, when I create a symbolic link is an autonomous file (with its own inode) with the length of exactly the source path plus a certain flag.

I guess my point is that it was a symbolic link and you are not guaranteed anything about how it was implemented. For instance under HFS+ it may well be a file (I don't know but it certainly seems reasonable).

Wow, I didn't know that. Which are these?

I remember that from my OS class of many many winters ago, I can't say that I remember the exact file system. The basic idea was that the target of the symbolic link was stored in filename slot of a directory entry and then had a bit set flagging it as "not a real file name". A symbolic link then did not index into the set of inodes but rather the directory index which contained the target.

The real moral of this is that with all the different implementations of this stuff over the ages for almost any cockamamy way you can come up with doing something somebody did it.

See, I'm really a rookie on filesystems, that is also new to me. But this is HPFS and not HFS+ is it?

Yes it is HPFS and I think that is part of the reason that there were never any Linux drivers able to write HPFS. It was just too different, that said I believe that NTFS has inherited some of these features and is in a similar situation of partial support.

I honestly just don't know what HFS+ does I haven't had reason to look it up.

Same for tcsh and bash.

Nope you misunderstood the ** that will match any number of arbitrarily nested directories. So /foo/**/bar.c would match /foo/baz/quuz/zot/bar.c which is not possible in bash or tsch. In those cases you have to use find to grovel over the directory for you. Another point is that this is very sow by comparison and on something like HPFS a wild inferiors match like above would be super fast.

Is now anyone here, who can answer my actual questions? Thanks again!

Well I thought I did in an obtuse sort of way which is to say you cannot in general do what you are trying to do. I also know this from experience in trying to use a combination of dd and fsck to delete an undeletable file. Nothing says that you can cat a directory or a symlink on any filesystem on any given unix. Now it may work on some implementations like my old 3b1 but it is just an accident really.

On a side note if I can write a directory via cat like you could in the old old days that also means that I can own the box. All I have to do is copy a shell into a directory, make it setuid me and then edit the directory file to change that little uid to root's. Now I am root and on my merry way.

Note to moderators that is not really a description of how to hack a box as it would not work on any modern computer.

So what are you really trying to do? Just make a symbolic link, that was already answered. Convert a normal file into a symlink using its contents as a target via some backdoor way?

-Eric

[Eckhart]

Without bringing it up at large, my questions were:

1. How do I make the system (in whatsoever way - and regardless to all the implementations over the ages it is not working on) to stop following symbolic links?
2. Is any "hack" known to somebody how I can dump a directory to stdout? As it was once possible -and not only one system- with "od -c".

Ok, and most about your point was basically that we cannot find a patent remedy due to all these different implementations and filesystems... -- which is an euphemism for "NO" to both questions.

Well, anyways I didn't want to bother, if the answer doesn't come handy, I did not want to start a major thread. It was just the idea that somebody would know.