It is possible for regular files to be
treated as both files and directories with
the directory part being subfiles.

	/foo/bar	regular file
	/foo/bar/@SPLAT@/subfile

but what about directories?

	/foo/@SPLAT@/subfile

There are probably answers to that question,
including "how unecessary" :).

I'll repeat myself. It's easy to get myopic about
this stuff. Sure, anybody can invent a namespace
trick (filesystem feature) to access subfiles.
Big whoop. Now, what about tar(1) and tar(5) and
NFSv4 and....... Does interoperability/interchange
still count?

Yes, there is already some divergence. Divergence
is bad. Convergence and interoperability are good.
At the very least, we should pick a method that
enjoys some measure of deployment and has answered
the interoperability/interchange questions and
follow it. It is not only unecessary to invent an
answer, it is likely counterproductive.

This isn't directed at der Mouse. Just this is the
Nth posting on "another way to do it." I had to
respond.

Regards,
	-gww


> -----Original Message-----
> From: tech-kern-owner@NetBSD.org [mailto:tech-kern-owner@NetBSD.org]On
> Behalf Of der Mouse
> Sent: Wednesday, June 29, 2005 4:55 PM
> To: tech-kern@NetBSD.org
> Subject: Re: CVS commit: src
> 
> 
> > There are filesystems that do something very similar to this except
> > with "foo@@" being the magic hidden directory for "foo".  From my
> > experience with that it works pretty well (provided you don't have
> > filenames that end in @@) since most programs treat files as files,
> > but if you explicitly use one of those special names the program
> > accessing the contents doesn't have to know that anything is
> > different from a normal directory hierarchy.
> 
> When I was in Norway, the second half of 2002, I was doing filesystem
> work.  In particular, I built a pseudo filesystem layer, which placed
> the split basically at the VOP_* call point.
> 
> The use that was made of this was making a research storage project
> mountable as a filesystem.  This particular project was rather
> seriously unlike Unix filesystem semantics, and much of the work
> involved was figuring out how to design the impedance-matching layer.
> 
> The relevance at the moment is that one of the things involved was that
> the thing that was presented as a file actually had a lot more
> structure than just the array-of-bytes contents.  I implemented this as
> very much what's being talked about here: if you have a file /foo/bar,
> then you can treat it as a directory; if you do so, the directory you
> see contain various files with fixed names whose contents are the
> various pieces of that additional structure (possibly things other than
> files, such as symlinks - I forget the details).  It worked fine.
> 
> /~\ The ASCII				der Mouse
> \ / Ribbon Campaign
>  X  Against HTML	       mouse@rodents.montreal.qc.ca
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
> 
>