cache_lookup() work this week.

Jan Grant Jan.Grant at bristol.ac.uk
Fri Sep 12 06:18:19 PDT 2003


On Fri, 5 Sep 2003, Matthew Dillon wrote:

> :>
> :>     This is a good one, and easy to solve... rm would just unlink() or
> :>     rmdir() the directory first, whether it is empty or not.  If the unlink
> :>     succeeds then rm considers its work done.
> :>
> :>     The last instance of the directory would not be unlinkable... rm -rf
> :>     would have to recurse through and delete the underlying files first.
> :
> :
> :mkdir -p /a/b/c/d/e
> :ln /a/b/c /a/b/c/d/e/f
> :rm -r /a/b
> :
> :...leaves an unreachable cycle.
> :
> :There are advantages in having a DAG for directory trees. I'm still
> :trying to figure out what good permitting cycles does.
> :
> :
> :--
> :jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
>
>     Yup.  The issue with preventing cycles... and I think it is a good
>     idea to prevent cycles... but the issue is that while you can prevent
>     a cycle from occuring at the time you create the hard link, how do you
>     prevent a cycle from occuring due to a later rename of some parent directory?
>     Short of scanning the entire subhiearchy when renaming I see no way to
>     detect the cycle.

Sorry, missed this earlier. Yeah, in general, you need to search a
subtree. As a useful heuristic, you might assume that most directories
won't be crosslinked, in which case you need to search the tree of
parents of the target (destination) directory, upwards, looking for the
directory you're intending on linking to. In the common case (none of
these crosslinked) that's linear; obviously, however, pathological cases
can arise. Even worse, they can be created deliberately from userland.
At the least, I'd restrict directory crosslinking to a suser operation
in consequence.


-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/
I'm the dandy information superhighwayman.






More information about the Kernel mailing list