Re: FS: hardlinks on directories

[Jesse Pollard <jesse@cats-chateau.net>]

On Monday 04 August 2003 09:50, Stephan von Krawczynski wrote:
> On Mon, 4 Aug 2003 15:04:28 +0100 (BST)
>
> Anton Altaparmakov <aia21@cam.ac.uk> wrote:
> > For a start the kernel VFS dcache would break because you end up with
> > multiple entries for each inode, one entry for each parallel directory
> > tree.  Read-only you are just about able to get away with it (been there,
> > done that, don't recommend it!) but allow files to be deleted and it will
> > blow up in your face.
>
> I cannot comment, I have no inside knowledge of it.
>
> > You ask for examples of applications?  There are millions!  Anything that
> > walks the directory tree for a start, e.g. ls -R, find, locatedb, medusa,
> > du, any type of search and/or indexing engine, chown -R, cp -R, scp
> > -R, chmod -R, etc...
>
> There is a flaw in this argument. If I am told that mount --bind does just
> about what I want to have as a feature then these applictions must have the
> same problems already (if I mount braindead). So an implementation in fs
> cannot do any _additional_ damage to these applications, or not?

Mount -bind only modifies the transient memory storage of a directory. It 
doesn't change the filesystem. Each bind occupies memory, and on a reboot, 
the bind is gone.

> My saying is not "I want to have hardlinks for creating a big mess of loops
> inside my filesystems". Your view simply drops the fact that there are more
> possibilities to create and use hardlinks without any loops...

been there done that, is is a "big mess of loops".

And you can't prevent the loops either, without scanning the entire graph, or
keeping a graph location reference embeded with the file.
Which then breaks "mv" for renaming directories... It would then have to
scan the entire graph again to locate a possble creation of a loop, and 
regenerate the graph location for every file.