In article <3994668D.97713419@holly-springs.nc.us>,
Michael Rothwell <rothwell@holly-springs.nc.us> wrote:
>Christopher Vickery wrote:
>
>> I'm interested in implementing a system that associates
>> meta-data with inodes, and would like to know if it has
>> already been done or is in the works.
>
>None has. There's two different ways of doing it currently;
>the BeOS way and the NT way. As you said, NT makes a
>namespace augmentation, using the ":" character to
>deliniate attribute names from file names. This is called
>"named streams". BeOS does not do that, but provides
>special accessor functions instead; this is called
>"extended attributes." They both accomplish the same
>goal though: keeping extra data about a file with the file.
Note that this is a subset of what I wanted to make sure the Linux VFS
layer can do: if a filesystem has multiple forks in a file, the VFS
layer should be able to handle it by just doing the normal "readdir()"
and "lookup()" on such regular files.
Of course, no UNIX filesystem does this, so it has never gotten any
testing. But the plan was (and is) that if somebody wants to implement
resource forks, then it should be possible without any hackery.
Linux does _not_ use the ":" character, of course. Linux uses the same
old "/" that it always uses for delineating names. That's pretty
built-in into the VFS layer.
But it definitely should not be impossible to have a file called
~/myfile
and then access the "Icon" resource in it by just doing
xv ~/myfile/Icon
It requires that the low-level FS know what it is doing, and it may
require some changes (small) to the VFS layer just because it has never
been done before (and I'd be surprised if such resource forks didn't
uncover _something_), but it should be entirely doable.
Of course, Linux doesn't have a good interface to look up a resource off
an already opened file, but it would be quite easy to add a
fd = fd_open(fd, "Icon", O_RDWR | O_CREATE, 0666);
which would essentially be the same as "open()", except it would start
from "fd" instead of "cwd" like a regular open. There have been reasons
to have something like this before (you can emulate it in a ugly manner
by doing something like
int fd_open(int fd, const char *name, unsigned int flags, unsigned int mode)
{
int retval;
int tmpfd = open(".", O_RDONLY | O_DIRECTORY);
retval = tmpfd;
if (tmpfd >= 0) {
retval = fchdir(fd);
if (!retval) {
retval = open(name, flags, mode);
fchdir(tmpfd);
}
}
return retval;
}
but that's fairly cumbersome and slow compared to how simple it is to do
this in the kernel.
Of course, right now there is no real use for this. But resource forks
might become the use.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:26 EST