Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: NTFS-like streams? | Date | 11 Aug 2000 19:58:02 -0700 |
| |
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/
| |