![]() | |||||||||||||
Messages in this thread |
Hans Reiser wrote: > If we also add to this the restriction that once you create the file > part of a file-directory, you can never hardlink to a child of it, it > should then all work, yes? > > So, /filename/..../owner should be able to avoid colliding with any > common names by virtue of the '....', and not letting any filedir > (file-directory) have children with links to them should also work. The > one thing that seems inelegant is that when you create the file part of > a filedir, you must check all its children for hardlinks and fail if > they exist, and you must flag all its directory children so that the > plugins for them will disallow hardlinks to their children from that > point onward. Still, seems workable.... Ok, still haven't heard much discussion of metafs vs file-as-directory, but it seems like it'd be easier in metafs. Basically, we are entirely POSIX compliant outside of metafs, so that /filename is a file and may be hardlinked, and /directory/ is a directory and may not. No problems yet. Inside /meta/inode, we have no problems yet because any hardlinks created outside /meta won't even show up as hardlinks here, so we don't get hardlinked directories. Inside /meta/vfs, where we can find the metadata of '/filename' under '/meta/vfs/filename/...', we have what looks like a problem -- we may have hardlinks created outside metafs, which will show up as two directories inside metafs, so those directories are hardlinks. I don't think that's such a problem, since we won't allow users to change anything in /meta/vfs except when it's inside metadata, such as '/meta/vfs/some/where/...'. Thus, it's impossible to create a hardlink to a directory unless we do it *outside* metafs, as a hardlink to a file. Now, the question I asked is, what if we want hardlinks *inside* metafs, *inside* the metadata for a given file, and would we ever want such a thing? Because we can avoid the whole problem if we just disallow any sys_link calls inside metafs. Of course, sometimes we want to have a chunk of metadata that appears *exactly* as if it were a normal, POSIX-compliant directory tree, such as the contents of a tarball or a zipfile. In that case, we might want to have the "zip" plugin allow hardlinks inside "/meta/file.zip/.../contents" -- the only restriction is that any hardlink made to a file inside 'contents' must be made to another file inside 'contents'. > Hans Reiser wrote: > > >>David Masover wrote: >> >> >> >> >>>Now, can anyone think of a situation where we want user-created >>>hardlinks inside metadata? More importantly, what do we do about it? >>> >>> >>> >>> >> >>I think the equivalent of symlinks would be good enough to get by on for >>now for most linking of metafiles. Maybe some years from now somebody >>can fault me for saying this and write a patch to fix it to be better, >>at which point I will be happy to concede the point. >> >>So the basic principal here is, one can have hardlinks to directories >>without cycles provided that one does not allow any child of the >>directory to have a hardlink. The question is, how cleanly can that >>relaxed restriction be coded? >> >>Hans >> >> >> > > - 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/ | ||||||||||||
| Last update: 2005-07-06 21:33 [from the cache] ©2003-2008 | |||||||||||||