Rogier Wolff wrote:
> Right. And I'm suggesting that an access method can and SHOULD be
> designed that works exactly the same on filesystems that support it and
> on filesystems that don't.
That seems more or less like not actually
supporting streams at all.
> Right. It's not the actual NAMES of the HFS tricks that I'm proposing
> to keep. I'm saying that we should try to make something generic which
> will allow NTFS named streams and HFS resources to both be accessed in
> similar ways, and also in such a way that you almost don't notice it
> when you unpack it on a normal posix filesystem.
Why? Do posix FSes care about EAs?
> The .Appledoube/myfile hack satisfies that requirement.
In a very ugly way -- sort of like using that "tire
in a can" to fix a flat. Yeah, it plugs the hole. How
is "mv" supposed to work with ".LinuxDouble" directories?
> As Apples have only one resource,
Mac OS X supports arbitrary streams.
> this "myfile" would need to be a directory with the
> stream-names in there for NTFS, or the other way around, the filename
> should be a directory with the resources in there.
Cripes. Nextstep again. Let's make everything look like a
posix FS, but make everything else about filesystems and
applications look like RiscOS or NextStep. That's actually
_more_ disruptive.
If the streams access method we decide on is a _superset_
of posix Fs requirements, what's the problem? Posix apps
still get what they expect. So extending the namespace
to provide streams support seems like a reasonable idea.
-Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:33 EST