On Sat, 16 Apr 2011 17:33:39 -0000 [email protected] wrote:
> ron minnich <[email protected]> writes:
>
> > If you look at what a hard link is, you'll realize why they are not in
> > Plan 9.
>
> It's not that obvious to me. A hard link is another name for a file,
> uniquely identified by <type,device,qid>. The effect of a hard link can
> be simulated with bind, but requires managing a list of excetions (one
> bind for each "link"). If the binding were done server-side, there
> would need to be some additional protocol element (perhaps a Tbind
> request) to add another name to a file. The semantics of Tbind could
> meaningfully be extended to all types of files, not just disk files.
You are focusing on "how" to implement it, not "why".
Ask yourself *why* do you need it. Is it just convenience
(what you are used to) or is there something you do that
absolutely requires hard links? Next compare the benefit
of hardlinks to their cost. It is worth it?
Hard links force certain design choices and make things more
complex. For instance, you have to store the "inode"
(metadata) of a file separate from its name(s) so if you lose
all of its names, you need a way to garbage collect the object
(or add a name) -- what fsck does. If there is just one name,
you can store the metadata along with the name -- a simpler
choice; you don't need to allocate a separate disk area for
inodes.
Next, you can only hardlink on the `same device' so now the
underlying device is no longer transparent (i.e. something you
can ignore) and you can't be sure if
ln <path1>/a <path2>/b
will work. A more complex user model.
Next, Unix typically only allows hardlinking of files and not
directories (to avoid creating accidental loops -- detecting
loops is considered more complex for some reason). So more
restrictions.
Next, the concept of hardlink is not particularly useful or
doesn't even make sense for synthetic filesystems (such as
devices or environment or basically anything that can benefit
or be more easily accessed given a collection of names and
often these names have special meanings). What would it even
mean if you allowed "ln /proc/123 /proc/324"? So even in unix
where special filesystems are allowed such operations are
banned. So more restrictions.
A more useful concept is that of a `view' on a collection of
things rather than hardlinking individual files. bind/mount
already give you that.
Coming from a Unix environment you have learned to live with
the complexity of and restrictions on hardlinks and very
likely you think of filesystem names as almost always
referring to files that store data or directories. "Unlearn"
unix rather than try to recreate it in Plan9!
