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/