What about using // as some URI entry point? An URI looks like: PROTOCOL://PROTOCOL_SPECIFIC_NAMESPACE_IMPLEMENTATION
As no one can guarantee unix semantics in an URI space only symbolic links are allowed to and from the URL namespace. The "protocol" names are issued by the kernel to prevent clashes and fragmentation. Some example URI's for a userspace implementation like fuse. //http://somehost:port/foo/bla //tar:///path/to/some/file.tar.gz/sub/directories That could unify the namesspace for userspace apps like gnome, kde and mc. The / could even mean a shortcut to the //file:// URI, but loosing the capability to hardlink. If someone wants to expose filesystem metadata something like //metas:// instead of //: could do it. //metas://a-directory/SomeName regular dir entry //metas://a-directory//SomeName named stream //metas://a-directory///SomeName == //metas://a-directory/SomeName The same applies to files as well... //metas://foo.txt/SomeName ERROR //metas://foo.txt//SomeName named stream //metas://foo.txt///SomeName == //metas://foo.txt/SomeName == ERROR And for the root dir also... //metas:/// root //metas://// root's named stream dir, looks odd but has // after //metas:// //metas:///// root, has /// after //metas:// and means / == root dir //metas:///. root //metas:///.. root //metas:///./ root //metas:///.// root's named stream dir //metas:///./// root //metas:///./. root //metas:///./.. root //metas://./ curr dir //metas://.// curr dir's named stream dir //metas://./// curr dir //metas://./. curr dir On Thursday 09 September 2004 12:41, David Dabbs wrote: > > During the recent reiser4-related namespace/semantics discussions, Alan Cox > [http://marc.theaimsgroup.com/?l=reiserfs&m=109405544711435&w=2] and others > referred to the Single UNIX Specification v3 (SuS) provision for > implementation-specific pathname resolution. After a close reading of the > SuS, here is a proposal for how we might flexibly and legally accommodate > new filesystem features. > > Assumption > * "Named file streams" (file-as-dir/dir-as-file/whatever) are worth > implementing, if only to provide Windows interoperability for Samba. > > Goals > * No breakage for naïve applications. > * No new APIs e.g. openat(). > * Maintain POSIX/SuS compliance. > * Expose the "named streams" capability via the natural "collection of > files" approach as Linus called it. > [http://marc.theaimsgroup.com/?l=reiserfs&m=109353819826980&w=2] > > Caveat > Other than punting and prohibiting linking to objects created with > a container attribute, this proposal doesn't present a solution to thorny > issues such as locking. > > In A Nutshell > > //:a-directory/SomeName regular dir entry > //:a-directory//SomeName named stream > //:foo.txt//SomeName named stream > //:/.// root's named stream dir > > > Still interested? Read on. > > > > What the Spec Says > > All Directories Are Files, but Not All Files Are Directories > In SuS (3.163 File), a file is "an object that can be written to, or read > from, or both. A file has certain attributes, including access permissions > and type. File types include regular file, character special file, block > special file, FIFO special file, symbolic link, socket, and directory. Other > types of files may be supported by the implementation." This last bit is > encouraging, as we are free to implement new file types. > > Can An Object Be More Than One Type? > Recent debate hovered around notions of "file-as-dir" or "dir-as-file," but > is this legal? Everywhere the SuS mentions file types they are referred to > as "distinct file types." I didn't scan all the threads for technical > objections to file type duality, but it seems like we should steer clear of > objects that are more than one S_IFMT type. Suppose we implement a container > type. Is it permitted for an object to be both a file and a container? > > Pathname Resolution > Whatever innovations people dream up, applications still need to provide a > pathname to the existing APIs. All manner of proposals were floated for > "named streams" -- from reiser4's "/metas" to prefixes such as ".$" or > "...". [http://marc.theaimsgroup.com/?l=reiserfs&m=109413602520921&w=2] > > According to SuS 4.11 Pathname Resolution, > http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_0 > 4_11 > ... > A pathname that begins with two successive slashes may be interpreted in > an implementation-defined manner, although more than two leading slashes > shall be treated as a single slash. > .... > > // seems relatively clean, but if more than two leading slashes equate to > one, how would an absolute path be specified? How about: > > //:foo/bar/baz relative path to foo/bar/baz > //:/foo/bar/baz absolute path to /foo/bar/baz > > While other characters would work, colon seems to fit because "//:" is the > reverse of "file://" minus file. > > > The Directory Problem > Among the issues raised is disambiguating a stream object name from an > identically named object within a directory. With pathnames prefixed by //:, > one could use something as simple as //, e.g. > > //:a-directory/SomeName regular dir entry > //:a-directory//SomeName named stream > //:a-directory///SomeName == //:a-directory/SomeName > > The same applies to files as well... > > //:foo.txt/SomeName ERROR > //:foo.txt//SomeName named stream > //:foo.txt///SomeName == //:foo.txt/SomeName == ERROR > > And for the root dir also... > > //:/ root > //:// root > //:/// root > > //:/. root > //:/.. root > //:/./ root > //:/.// root's named stream dir > //:/./// root > //:/./. root > //:/./.. root > > //:./ curr dir > //:.// curr dir's named stream dir > //:./// curr dir > //:./. curr dir > > No characters or words are removed or reserved from the 'normal' namespace. > A person named Metas can still use his/her name on files, and script kiddies > can still use "...". Applications that got away with pathnames with two > embedded slashes would need to be precise when using the new pathnames. > > Named Streams on Named Streams? > If we want to do no more than allow named stream compatibility with NTFS, > then we can prohibit "names on names". The directory referenced by foo// > would be flat, with only one level of files allowed. Attempts to create > something like //:/a-directory//SomeName//Another would return an error. It > doesn't seem like there's any reason to disallow names on names, though. > Stream-aware applications would simply discard the deeper streams (or > subdirectories) in the same way that named streams are discarded when > copying from NTFS to Linux. > > VFS Support > Apps written to take advantage of the new pathname semantics will need to > know whether it is supported under the current configuration. Would > statvfs() be the place to inquire whether "alternate namespace" support is > available? Would it also be necessary to require apps to query for the > "alternate pathname prefix character" e.g. ":"? Doesn't seem necessary. > > link_path_walk() and other namei.c functions will need changes to support > the // semantics. If a path component is followed by // then a macro such as > S_ISCONTAINER(stat_t) must be true. > > super_operations would need a way for filesystems to expose their support > for the "named streams" or "container" capability. > > Any named stream object storage must count toward quotas. > > > The Linking/Locking Problem > Al Viro points out a number of serious, unaddressed issues > [http://marc.theaimsgroup.com/?l=reiserfs&m=109463622427391&w=2] > including > > > Locking: see above - links to regular files would create directories > > seen in many places. With all related issues... > > If this cannot be solved then we can simply punt and decide that the > container property is not automatic for all files and directories on > filesystems that support the capability. This would be specified when the > file or dir is created and linking to such an object would be prohibited. > > Linking to a container or to contained object presents problems, but > creating links out of the container seems like it would be just like any > other link object, yes? > > > Other Unaddressed Issues > Alan Cox > > Another interesting question btw with substreams of a file is what the > > semantics of fchown, fstat, fchmod, fchdir etc are, or of mounting a > > file over a substream." > > Al Viro > > Note that we also have fun issues with device nodes (Linus' "show > > partitions" vs. "show metadata from hosting filesystem"), which makes > > it even more dubious. We also have symlinks to deal with (do they have > > attributes? where should that be exported?)." > > > > David Dabbs > > -- lg, Chris
