Messages in this thread |  | | From | "Albert D. Cahalan" <> | Subject | Re: abstract file (multi-part one file or multiple files?) | Date | Sun, 20 Aug 2000 15:17:45 -0400 (EDT) |
| |
Clayton Weaver writes:
> This is to some extent a disagreement over terminology. When we say > "file", are we talking about the user interface or the implementation?
A file has these properties:
1. it can not be the current working directory of a process 2. it can be atomically unlinked 3. it has a single ACL (or UNIX permission bits, or whatever) 4. it can be hard-linked if the filesystem supports hard links 5. it has exactly one inode number 6. it has a visible name (ignoring hard links and deleted files) 7. it is of type S_IFREG (but note: directories may have streams too) 8. it has at least one stream, just as a process has threads
A stream has these properties:
1. it is a blob of data w/o OS-interpreted structure 2. it shared (inheritance WITH UPDATE) properties with others 3. it can not be independently hard linked 4. it has no normally visible name 5. st_mode has no meaning, except to describe the parent type 6. streams themselves do not have streams
> The complex document file is not a directory in the way that users > understand directories, as an hierarchy of folders for storing objects > that can be single-part or multi-part, but it needs to be implemented like > a directory. The VFS must recognize that a multi-part storage object that > is not explicitly a directory at user level has a directory implementation > but has constraints on what can be nested in it that an explicit directory > does not have.
One may implement complex document files using multi-streamed files or, less efficiently, using single-streamed files. Using multi-streamed files is a performance hack that may require some sort of format-specific loadable module. Microsoft actually does have such kernel support for the *.doc format. The concept isn't at all alien to Linux; look at all the IP masquerading helpers.
(the kernel module exists only to solve the "lost stream" problem) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |