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

Reply via email to