Re: silent semantic changes with reiser4

[Linus Torvalds]

On Thu, 26 Aug 2004, Rik van Riel wrote:
> 
> Thinking about it some more, how would file managers and file chosers
> handle this situation ?

The same way they already handle it on other platforms that support it? By 
taking advantage of it..

People literally use this for icon and preview information, so some of the
stuff shows up very much in file managers. And I'd assume that a normal
double-click would just open the main file, and you can right-click for 
management information, including opening the file.

If you want an entity that acts as a directory, you create a directory. 

Directories don't go away - you still have S_ISDIR() and S_ISREG(), and 
they still return information. A file that has associated information is 
still a _file_, and people should treat it that way, it's just that it 
also has a list of named sub-streams. You can open it as a directory, but 
the stat information clearly says it is a file, and the "directory" view 
is very much associated with _that_ file.

I definitely don't think you want the file manager to act as if a named 
stream is exactly the same as a stand-alone file. They have all the same 
operations, but there's no question that there are differences too. 
Especially on a conceptual level - but for most filesystems there are 
likely real technical differences too.

For example, it's likely that most filesystems would _not_ allow linking 
of a named stream anywhere else. And you might not be able to change the 
permissions or date on the named stream either, since it may or may not 
have a separate date/permission thing from the container.

So don't believe that just because the named streams are _named_ like real 
files, that they suddenly have any existence beyond the container that 
they are part of.

There may be other limitations too - again depending on how the filesystem
actually implements named streams. It might not support more than one
level of naming, for example - so you might not be able to create a
directory structure within the named streams, for example.

In short: the fact that the VFS layer exposes the _capability_ to see the 
named streams as a full POSIX filesystem of its own does _not_ mean that 
the low-level filesystem necessarily allows the full possible semantics. 
So you shouldn't design your apps that know about named streams to think 
they are normal directories.

The directory thing is just a very powerful naming scheme, and one that 
fits into the existing UNIX model.

> Do we really want to have a file paradigm that's different
> from the other OSes out there ?

Different from what other OSes?

Last I looked, Windows, Solaris, and OSX all supported named streams. What 
other OS's are out there that you care about? 

In other words, this is _not_ a different paradigm from what others do.  
The discussion is whether we want to implement it at all, and more
importantly about syntactic issues (ie we clearly already implement
extended attributes, just with a much more limited syntactic power).

We don't have to go all the way. Solaris has "openat()", which is kind of 
a half-way there - not really directly available in the same namespace, 
but at least the result is available as a real file interface (as opposed 
to the Linux "xattr" interfaces that are _totally_ special-cased system 
calls).

In other words - the paradigm is already there. It's just that currently
it's pretty much unusable under Linux, because it requires so much
specialized knowledge that it's not worth it to modify existing apps. And
the interfaces are really very limited, so even if you _do_ end up using 
the specialized Linux interfaces, you can't actually do a lot of what you 
might want to do.

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/