[lkml]   [2000]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: abstract file (support multi-part)
On Sat, 19 Aug 2000, Clayton Weaver wrote:

> Thinking about Linus' message, my first intuition is that the
> sane approach is to support multi-part files natively in VFS as
> the default model of a file, and just drop all parts that are not
> applicable when accessing traditional unix files.

What extra parts are needed, though, and why? I haven't seen any mentioned
yet: enumerating the available "streams" (named blocks of data in a
directory - hrm. sounds like a file from here...) can be done with a
simple readdir().

> Linus says we should support multi-part files because filesystems
> for which they are the native model of a file already exist and
> aren't going to go away merely because they are messy compared to
> "simple" unix files.

That all depends on your viewpoint. If you fix the two major flaws in
NTFS's approach, what you are actually left with are just files. Files
which have part of their name in common with other files, yes - but does
that really matter to anyone?

> But traditional unix files are only simple from the point of view of
> user-space software. The single byte-stream is already a kernel fiction
> even in current filesystems that do not support multi-part files. The
> directory entry for a traditional file contains a variety of other
> information besides the inode number and the offset to and extent of
> the data blocks that represent the file's data.
> Multi-part files are like directories, but they don't have to actually be
> directories in the VFS. They need the same structure but different
> capabilities handling.

Not really. These are NOT parts of a single file: they are independent
blocks of data with names, living in a directory.

> Note: a "thumbnail" for an image or a "sticky note" is a user-space
> concept. For the kernel, it's just a nested multi-part file that is an
> attachment to the multi-part file that it is attached to. It can inherit
> the capability_constraints/acl parts from the parent file, but it's
> basename part, inode, and block offset/extent of its data are its own.

Nested? In what?? For a file "image.jpg", I may also have
"image.jpg:thumbnail" or similar. Does the kernel really need to know/care
about some theoretical link between the two??

> A VFS backend would handle filesystem-specific semantics for what the
> parts can be exactly, when they are required, etc, for legacy multi-part
> filesystems.
> So, in sum, "everything is a directory"?

"Everything is a file" is a much more logical approach, IMO. More
particularly, "every named block of data living on a filesystem inside a
directory is a file" seems pretty obvious...


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:37    [W:0.104 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site