Why aren't (hard) links to symbolic links allowed? - comp.unix.wizards

Message from discussion Why aren't (hard) links to symbolic links allowed?

Bob Goudreau

View profile

More options May 10 1990, 4:09 am

Newsgroups: comp.unix.wizards

From: goudr...@larrybud.rtp.dg.com (Bob Goudreau)

Date: 9 May 90 23:14:24 GMT

Local: Wed, May 9 1990 7:14 pm

Subject: Re: Why aren't (hard) links to symbolic links allowed?

  Reply to author
  |
  Forward
  | Print
  | View thread
  | Show original
  | Report this message
  | Find messages by this author
  

In article <1990May9.171340.5...@ucselx.sdsu.edu>, g-pat...@steer.uucp

(Mitch Patenaude) writes:

> In article <8...@nlsun1.oracle.nl> beng...@oracle.nl (Bjorn Engsig) writes:
> >........................... Shouldn't I be able to have more than one (hard)
> >link to a file that happens to be a symbolic link? If no, then why not?

> No.. in fact.. you don't even have one hard link... a symbolic link is
> just a specialized direcotry entry which makes reference to another
> filename (not even the i-node.. just the filename.. if the file it
> references is moved or deleted.. the link does not follow it).. while a
> hard link makes another link to the i-node (and becomes indistinguishable
> from the files it's linked to.) but the sybolic link has no i-node of it's
> own.. only the referce to another file.. which is where the link is made.

Sorry, but that just isn't so, at least on the 4.2/4.3 BSD file system
and on other UNIX file systems that implement symbolic links. The
target pathnames of symbolic links are *not* stored in directory
entries, but in data blocks that are reached via real, honest-to-god
symlink inodes. Where do you think the information reported by
lstat(2) comes from?

The answer to Bjorn's question is, sorry, that's just the way the
link(2) system call works. There's no way to tell it *not* to resolve
its first argument into a hard link if it isn't one already. So,
barring the invention of a new system call (llink(2) anyone?),
there's no way to get a handle on a symlink itself, as opposed to
the target of that symlink.

However, it is possible to achieve the same effect, provided you're
willing to go beyond the bounds of system calls and diddle directly
with the on-disk representation of the file system. If you know the
inode number of an existing symlink file (not its target, but the
symlink itself), you could rewrite an existing directory block so that
it has a new entry -- an entry whose link is to the desired symlink
inode. Of course, your system probably makes no guarantees about
handling multiple hard links to symlinks, so you're on your own if
you actually mount the file system and start using the links. In
particular, it would be interesting to observe the effects of
deleting one of the symlinks and then trying to resolve the remaining
one....

------------------------------------------------------------------------
Bob Goudreau +1 919 248 6231
Data General Corporation
62 Alexander Drive goudr...@dg-rtp.dg.com
Research Triangle Park, NC 27709 ...!mcnc!rti!xyzzy!goudreau
USA

Reply to author Forward