Messages in this thread | | | From | Jesse Pollard <> | Subject | Re: FS: hardlinks on directories | Date | Tue, 5 Aug 2003 09:20:41 -0500 |
| |
On Monday 04 August 2003 18:34, Stephan von Krawczynski wrote: > 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.
simple .. tar --one-file-system will not process past a mount point.
> This is the reason why I would in fact be satisfied with mount -bind if > only I could export it via nfs...
it's a MOUNT point. NFS doesn't export across mount points just as it doesn't allow exporting a NFS mounted directory.
> > > > 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.
think about what happens with a "rm -rf name". If there are two parents you cant remove the other parents link without first finding it. hard links do not have a marker. - 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/
| |