Messages in this thread | | | Date | Thu, 9 Sep 2004 05:03:42 -0400 | From | Theodore Ts'o <> | Subject | Re: silent semantic changes in reiser4 (brief attempt to document the idea ofwhat reiser4 wants to do with metafiles and why |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |