Re: ln -s Bug?
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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ln -s Bug?
Marcus Nutzinger [EMAIL PROTECTED] writes: But if I do the same, just with the -s option to create a symlink, the following happens: $ ls -l drwx-- 2 nuuz nuuz 4,0K 2007-11-01 15:13 dir -rw--- 1 nuuz nuuz0 2007-11-01 15:13 file $ 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. A symbolic link is just that: symbolic. The symlink target is merely a string that is interpreted only at the time the symlink is followed, other than that it has no inherent meaning at all. It does not even have to point to a valid file name, if you never try to follow the symlink you can put any kind of interpretation on the name of the target. For example, you can use a symlink as a kind of lock, encoding the owner pid into its target name. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ln -s Bug?
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
Re: ln -s Bug?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. I see! This means that the utility just doesn't want e.g. to resolve the absolute path of the symlink-target, because maybe it doesn't exist and maybe it will never exist and will only be used as lock (as Andreas wrote) or value holder. Now I also know why I didn't get it in the first place! I didn't realize that the first argument can also be non-existant. Now things are much clearer of course :) Thank you! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKhA9eEFjZ1Jaui4RAlm3AJ9IduMr9kuGsg2zjcWQOD9RmqoVcwCdHDPb k/kuFKKRy8BdvS0O4mVzwx8= =dc9Y -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
