DragonFly kernel List (threaded) for 2003-09
Re: cache_lookup() work this week.
: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
: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.
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@xxxxxxxxxxxxxxxxxxxx
Your comment for (C) answers your question in (B).