DragonFly BSD
DragonFly kernel List (threaded) for 2003-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cache_lookup() work this week.

From: Garance A Drosihn <drosih@xxxxxxx>
Date: Thu, 4 Sep 2003 14:10:54 -0400

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

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