Only now "cleaning" /tmp is not as effectve as it was. Pointing to no file but only filesystem blocks as every dir entry does. You don't get a dead or dangling link, you have a normal file. After cleaning /tmp and removing the "original", you happily go on using the same data blocks. Now you have a large bigfile in your working dir. Say you want to keep a big file on /tmp from being deleted and do ln /tmp/bigfile. So now with every rm, the kernel has to check: do I delete/free this file's blocks on the disk, or is there another file linked to the same blocks? For that, a link counter is used. A "link" at that stage of unix evolution meant that filename "B" (directory entry "B") in the filesystem points to the same inode as filename "A" is pointing to.įiles A and B are "linked" together, because they share the same blocks. Ln A B - copy whole file MINUS data blocks (=copy only inode and name), and increase "link count" for track keepingĪt this stage, there are links, but no hard and soft, and ls -l does not show arrows, because there is no direction in a (hard) link. And now I even use the source-target symbolism: mv A B - move the whole file to B (dir or new name)Ĭp A B - copy whole file (mv and cp are "the same" here) There was no soft and hard, no -s option. Symbolic links came later, so in the early days a link was just a link. On another level, the word "link" itself carries a deep hidden double meaning. You create it in one direction, so you can use it in the other. I don't have an arrow in the shell to show the direction of my link. Or you say: "I know this arrow notation in ls -l for links. The real target comes first, the extra fancy new link name second. Now if you are more demanding and want the link created under another name and/or somewhere else, you add that wish as name or path.
With the same name as FILENAME ("target" or "source"), right where you are. After ln -s /usr/lib/modules you get a modules -> /usr/lib/modules In the 2nd form, create a link to FILENAME in the current directory. See also very long addition at the bottom, addressing the iceberg, hard and soft of ln, not just the tip of it.
I put FILE or FILENAME instead of TARGET - see comments etc. If name2 is given, the link has that name This, together with the analogous "source"->"target" ordering of arguments to other basic tools, makes the non-GNU documentation for ln seem more natural.ĭESCRIPTION ln creates a link to an existing file name1. When you create the link, which is what you're doing with ln, the second argument, the thing that is created, is the "target" of the ln operation, and it's created using the first argument, the "source". However, that's only true when you use the link. It may seem obvious that the second argument, the thing that is created, should be the "link name" and that the first argument, the target of the link, is "target". Lrwxr-xr-x 1 kk wheel 11 Sep 15 11:39 README.txt -> hello worldĪ personal thought about GNU's choice to use "target" and "link name" rather than "source" followed by "target": There is usually no check made to validate that it points to anything useful: $ ln -s "hello world" README.txt Note that when creating symbolic links, the source is simply a string representing what the symbolic link should point at.
Or in other words, b is the target of the operation that creates a symbolic link using a as the source. Would create the symbolic link b pointing to a. mv and cp in that the target is what is created from the source. Ignoring the GNU choice of words, the ln utility follows the same semantics as, e.g.
UNIX LINK LN MANUAL
The GNU ln manual is the odd one out and calls the source target and the target linkname. Solaris /usr/bin/ln source_file ĪIX ln SourceFile The POSIX standard ln source_file target_file Most Unices document the ln command as ln source target
0 kommentar(er)
