Re: NTFS-like streams?

[Linus Torvalds]

In article <[e-mail]>,
Rik van Riel  <[e-mail]> wrote:
>On Sat, 12 Aug 2000, Michael Rothwell wrote:
>> Rik van Riel wrote:
>> 
>> > So what we want are directories, and not file streams?
>> > Oh wait, we already have those...
>> 
>> Not really. Directories aren't the same thing, 
>> and don't serve the same purpose. They're _similar_, 
>> but not identical.
>
>So what is The Big Difference(tm) that make file streams
>so much better than directories and so much different?

I'll talk really slowly.

HFS has resource forks.  They are not directories.  Linux cannot handle
them well. 

I'm all for handling HFS resource forks. It's called "interoperability".

It's also realizing that maybe, just maybe, UNIX didn't invent every
clever idea out there.  Maybe, just maybe, resource forks are actually a
good idea.  And maybe we shouldn't just say "Oh, UNIX already has
directories, we don't need no steenking resource forks". 

Put this another way: don't think about "directories vs resource forks"
at all. Instead, think about the problem of supporting something like
HFS or NTFS _well_ from Linux. How would you do it?

Suggestions welcome. What's your interface of choice for a filesystem
like HFS that _does_ have resource forks? Whether you like them or not
is completely immaterial - they exist.

And usability concerns _are_ real concerns. I'm claiming that the best
interface for such a filesystem would be

	open("file", O_RDONLY)		- opens the default fork
	open("file/Icon", O_RDONLY)	- opens the Icon fork
	open("file/Creator"...

	readdir("file")			- lists the resources that the file has

and I'm also claiming that the Linux VFS layer actually shouldn't have
any fundamental problems with something like this.

Tell me why we shouldn't do it like the above? And DON'T give any crap
about whether resource forks are useful or not, because I claim that
they exist regardless of their usefulness and that we shouldn't just put
our heads in the sand and try to hope that the issue doesn't exist.

		Linus