Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why

[Theodore Ts'o]

On Wed, Sep 08, 2004 at 12:09:52AM +0200, Robin Rosenberg wrote:
> Maybe file/./attribute then. /. on a file is currently meaningless. That does 
> not avoid the unpleasant fact that has been brought up by others (only to be 
> ignored), that the directory syntax does not allow metadata on directories.

*Not* that I am endorsing the idea of being able to access metadata
via a standard pathname --- I continue to believe that named streams
are a bad idea that will be an attractive nuisance to application
developers, and if we must do them, then Solaris's openat(2) API is
the best way to proceed --- HOWEVER, if people are insistent on being
able to do this via standard pathnames, and not introducing a new
system call, I would suggest /|/ as the separator as the third least
worst option.  Why?

Any such scheme will violate POSIX and SUS, since we are stealing from
the filename namespace, and thus could cause a previously working
program to stop working --- however, assuming that we don't care about
this, the virtical bar is the least likely to collide with existing
file usages, because of its status as a shell meta-character (i.e.,
pipe).  This means that in order to use it on the shell command line,
programs will have to quote it:

	cat /home/tytso/word.doc/\|/meta/silly-stupid-metadata-or-named-stream

This may seem to be inconvenient, but one very good thing about this
is that PHP and existing Perl scripts already already treat pathnames
that contain pipes with a certain amount of suspicion --- and this is
a good thing!  Otherwise, programs that take input from untrusted
sources (say, URL's or http form posts), may convert such input into a
metadata access, and that may be a very, very, very bad thing.  (For
example, it may mean that you will have accidentally allowed a web
user to read or possibly modify an ACL with whatever privileges of the
CGI-perl or php script.)  By using a pipe character, it avoids this
problem, since secure CGI scripts must be already checking for the
pipe character anyway.

> I'm not convinced that totally transparent access to meta-data actually 
> benefits anyone. If metadata is that useful (which I believe) it may well be
> worth fixing those apps that need, and can use them. The rest should just
> ignore it, even loose it. 

Totally agreed.  As I said above, I would prefer openat(2) to trying
to do this within a standard pathname, and I would prefer not doing it
all since aside from Samba, which is simply trying to maintain
backwards compatibility with a Really Bad Idea, the number of
protocols and data formats (ftp, tar, zip, gzip, cpio, etc., etc.,
etc.) that would need to be revamped is huge. 

						- Ted
-
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/