On Tue, May 22, 2007 at 08:48:49PM +0200, Miklos Szeredi wrote: > Why do we want this? > -------------------- > > That depends on who you ask. My answer is this: > > 'foo.tar.gz/foo/bar' or > 'foo.tar.gz/contents/foo/bar' > > or something similar. > > Others might suggest accessing streams, resource forks or extended > attributes through such an interface. However this patch only deals > with the non-directory case, so directories would be excluded from > that interface. > > But otherwise this patch doesn't limit the uses of the "file as > directory" concept in any way. It just adds the infrastructure to > support these whacky beasts. > > How is it done? > --------------- > > (See this [1] thread for more discussion on the subject) > > When a non-directory object is accessed without a trailing slash, then > path resolution returns the object itself as usual. > > If a non-directory object is accessed with a trailing slash, then the > filesystem may opt to let the file be accessed as a directory. In > this case "something" (as supplied by the filesystem) is mounted on > top of the non-directory object. > > This mount will have special properties: > > - If there's no trailing slash is after the file name, the mount > won't be followed, even if the path resolution would otherwise > follow mounts. > > - The mount only stays there while it is referenced by some external > object, like a pwd or an open file. When it is no longer > referenced, it is automatically unmounted. > > - Unlike "real" mounts, this won't block unlink(2) or rename(2) on > the underlying object.
Interesting... How do you deal with mount propagation and things like mount --move? As for unlink... How do you deal with having that thing mounted, mounting something _under_ it (so that vfsmount would be kept busy) and then unlinking that sucker? I'll look through the patch tonight; it sounds interesting, assuming that we don't run into serious crap with locking and <shudder> revalidation logics. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
