Messages in this thread | | | Date | Tue, 5 Aug 2003 01:34:25 +0200 | From | Stephan von Krawczynski <> | Subject | Re: FS: hardlinks on directories |
| |
On Mon, 4 Aug 2003 16:16:39 -0500 Jesse Pollard <jesse@cats-chateau.net> wrote:
> > > 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.
What kind of an argument is this? What difference can you see between a transient loop and a permanent loop for the applications? Exactly zero I guess. In my environments nil boots ought to happen. This is the reason why I would in fact be satisfied with mount -bind if only I could export it via nfs...
> > 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.
Or marking the links as type links somehow.
> 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.
There should be no difference if only a hardlink is simply marked as such by any kind of marker you possibly can think of.
Regards, Stephan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |