Powermaster
Site Supporter
How would one go about making a Symbolic Link?
Thanks
Thanks
How to make Symbolic Links
- Thread starter Powermaster
- Start date
hazmat
Rusher of Din
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?
/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?
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!
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
Mitä?
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
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
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.
Wow, I didn't know that. Which are these?
See, I'm really a rookie on filesystems, that is also new to me. But this is HPFS and not HFS+ is it?
Same for tcsh and bash.
--
Is now anyone here, who can answer my actual questions? Thanks again!
lurk
Mitä?
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).
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.
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.
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.
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
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.
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.