bug-fileutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: symbolic link sanity


From: Bob Proulx
Subject: Re: symbolic link sanity
Date: Sat, 2 Jun 2001 12:45:38 -0600

> Content-Type: text/html;

HTML mail is not appreciated by many on the net.  It would be
appreciated if you would avoid posting HTML to mailing lists.

Thank you for your report.  But I can't make sense of it.

> If a link like
> ln a /c/b
> is made no check on the relative location of a to b is made thus no
> relative link route via c will
> every be established in this manner.
> This may be regarded as a missing feature depending on your point of
> view. In this example the link is to be carried out in a directory other
> than /c.I am currently looking at fileutils version 4.0.

I see no relative link in your command.  You are showing "ln a /c/b"
and if "a" in the current directory is in the same filesystem as "/c"
then /c/b will be created which is a link to the same file that a
points to.  The link count will be increased by one, which can be
shown by use of "ls -il" which displays the link count and the inode
number.

Remember that directory names point to file inodes.  If two names are
links to the same file then they are both pointing to the same
underlying file.  They will share all file attributes such as owner,
group, permissions, etc.  But this can only happen on the same
filesystem.

You may be thinking of symbolic links which are created with ln -s.
That creates a name redirection.  When a symlink is accessed the
filesystem will take the contents of the symlink as a redirection to
another file, where the process may recursively be continued many
times.  If you were meaning "ln -s a /c/b" then that would create /c/b
which would be a relative symlink to file "/c/a".  If /c/a did not
exist then this would be dangling until such time at that file was
created.  The owner, group and mode of a symlink are not significant
to file access through it.

Symbolic links may use either absolute or relative paths but there are
tradeoffs.  Generally I advocate making only relative links so that
the location is network independent and will work desirably across NFS
mounted filesystems.

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]