This is to some extent a disagreement over terminology. When we say
"file", are we talking about the user interface or the implementation?
At user level, a graphic, for example, it's attached thumbnail, and an
attached  description are part of the same complex "file", and it is a
file, not a directory, even if the different parts are implemented as
discrete unix type files, each with it's own name in a directory entry,
on backing store. The directory-like implementation of it is
meaningless to a user of the object.

A multi-part "file" is a multi-part "storage object". What links
the parts together is a filesystem storage object model that extends
the "parent namespace linking associated non-directory leaf objects and
subdirectories" semantics of unix directories to an implementation
of storage objects that do not necessarily have the full directory
semantics of explicit directories (like document files with nested
streams: attempting to nest an explicit subdirectory like
"/usr/local/this_or_that/" in one should return ENOTDIR, but nesting
a multi-part storage object for a graphic image in one is reasonable).

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.

If you add per-file access control lists to unix filesystems, multi-part
is a natural VFS view of unix files, too.

Regards,

Clayton Weaver
<mailto:cgweav@eskimo.com>
(Seattle)

"Everybody's ignorant, just in different subjects."  Will Rogers



-
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/