cache_lookup() work this week.

[Matthew Dillon]

: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?  Something like 'find' will descend down
:into /a/b/c/d and only find itself back at /a/b (but with a
:longer pathname...).  There won't be a good way for 'find'
:to avoid that kind of loop, if I understand this correctly.

    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.  Only the (rdev,inode#) for the elements representing
    the current path need to be remembered so the memory use is small.
    e.g.:

    a[1,23]/b[1,55]/c[1,78]/d[1,55]

    In this case d[1,55] is a hardlink to b.  find, rm, whatever would
    see that the identifying information [1,55] is the same as for b
    which is still in its path and not recurse through it.

    It is an easy trick to implement.

:>     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?
:
:>     and (C) to be able to CD forwards and backwards without
:>     the system getting confused about paths.
:
:This would be nice!
:
:-- 
:Garance Alistair Drosehn            =   gad at xxxxxxxxxxxxxxxxxxxx

    Your comment for (C) answers your question in (B).

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>