Paul Eggert wrote: > Marcus Nutzinger <[EMAIL PROTECTED]> writes: > > could anyone please explain in > > a few sentences, why the program behaves in this way? > > Because that's how the "symlink" system call behaves. It can't easily > adjust the link to "work" in the way that you like, because it doesn't > have enough information available in general. Consider the case, for > instance, where you type "ln -s a b/c/d" and b/c is a symbolic link.
> > $ ln -s file dir/ > > $ ls -l dir > > lrwxrwxrwx 1 nuuz nuuz 1 2007-11-01 15:14 file -> file > > > > So "file" points to itself and not to "../file" as I would expect it > > after creating the link. Let me add that symbolic links are name translations. The value of the symbolic link is the string that you use to create the symbolic link. On some operating systems the size of the symlink is the number of characters in the link. On my system the above size is four characters to hold "file". The value of the symlink is always the literal string (within validity limits) given on the command line. For the reasons Paul said the name can't be modified from what is specified on the command line because in general it can't know what is wanted. What you say is what you get. Nothing more and nothing less. It does not need to exist at the time that it is created. It may only be valid in some future context. Or it might never be valid as some applications use them only for the holding of a value and nothing more. $ ln -s 4321 barlink ...some time passes... $ echo some data > 4321 Hard links (ln without the -s option) are immediate filesystem links of the inode of the two files. The inode reference count will increase. The directory will hold a pointer to the file. The file then exists on the filesystem by both canonical paths. This is not a name resolution. The file now resides in the new location. And in the old location too. The file must exist ahead of time. The file can only be linked on the same filesystem. Links across filesystems can't work. Bob _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
