From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Sat, 16 Apr 2011 17:33:39 -0000." <86d3km6qz0.fsf@cmarib.ramside> References: <8662qej52i.fsf@cmarib.ramside> <86d3km6qz0.fsf@cmarib.ramside> Date: Sat, 16 Apr 2011 11:22:13 -0700 From: Bakul Shah Message-Id: <20110416182213.8E1D5B849@mail.bitblocks.com> Subject: Re: [9fans] Q: moving directories? hard links? Topicbox-Message-UUID: d08b516e-ead6-11e9-9d60-3106f5b1d025 On Sat, 16 Apr 2011 17:33:39 -0000 smiley@zenzebra.mv.com wrote: > ron minnich 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 . 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 /a /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!