Re: cache_lookup() work this week.

[Garance A Drosihn <drosih@xxxxxxx>]

At 11:55 PM -0700 9/3/03, Matthew Dillon wrote:
> :At 10:10 PM -0700 9/2/03, Matthew Dillon wrote:
> :>     The fourth step will be a *BIG* Carrot...
> :>     This means that (A) it will be possible to hardlink
> :>     directories,
> :
> : Isn't this dangerous?  What if you have a hardlink between
> : /a/b/c/d and /a/b?
>
>     It's very easy to find loops.  All the program has to
>     do is record the (rdev,inode#) for each directory
>     element in the path as it recurses.

Oh. Yeah, that would work.  Pretty obvious now that you mention
it...  Still, we're not talking about a single program that
needs to be fixed.  A lot of programs would need to be fixed
(including ports, or even scripts that users have written) .

Consider also:
   cd /a/b/c/d   ;  ln /a/outside
Time passes, and someone else types:
   cd /a/b/c     ;  rm -Rf *

The person will think that they are just safely removing the
directory and everything below it, but now they could be
removing much more than that.  We'd have to do something to
guard against that problem too.  (and these hard links could
be created by users with nefarious purposes in mind, so the
person doing the 'rm' would have no reason to suspect that
this would be an issue).

>     Only the (rdev,inode#) for the elements representing
>     the current path need to be remembered so the memory
>     use is small.

If we're going to have real hard-links, then it would probably be
important to add a a "number-of-hard-dirlinks" field to stat().
This would be a separate value from the st_nlink field, in that
it would only count the number of directory hard-links.  Maybe
call it st_ndirlink.  Then any program which wants to do this
will only have to remember (rdev, inode) for those directories
where this value is > 1.  That makes the overhead even less...

This field might also provide a way to address the 'rm' problem
mentioned above.  If st_ndirlink > 1, then just destroy the hard
link and do *not* remove the files underneath the hard link.

But I'm still very uneasy with the idea of real hard links on
directories.  I think it's too much potential for trouble
without enough of a benefit.

> :>     and (B) it will be possible to implement semi-hard
> :>     links, basically softlinks that *look* like hardlinks
> :
> :What will this be like?  Ie, what will be the difference
> :between hard-links and semi-hard links?  Will this be
> :something like the way OpenAFS handles volume-mounting?

On this question, I just curious in the lower-level details,
so it's different than my hard-links question. I definitely
like this idea, I was just wondering how it'd be implemented.
From other messages it does sounds like you intend to implement
this in about the same way that OpenAFS does volume-mounting,
which is what I was wondering.  Thanks.

--
Garance Alistair Drosehn            =   gad@xxxxxxxxxxxxxxxxxxxx
Senior Systems Programmer           or  gad@xxxxxxxxxxx
Rensselaer Polytechnic Institute    or  drosih@xxxxxxx