Re: abstract file (support multi-part)

["Albert D. Cahalan" <acahalan _at_ cs.uml.edu>]

James Sutherland writes:
> On Sun, 20 Aug 2000, Mo McKinlay wrote:
>> Today, James Sutherland <jas88 _at_ cam.ac.uk> wrote:

>> What you are left with is a file made up of more than one part.
>
> That all depends on how you define "file" - is it "an MFT record" or
> "a block of data with a name"? If the latter, streams ARE files.

The former. Sorry if you don't like it.

>> Not multiple files. And not fixing the "two major flaws in NTFS's
>> approach" - it's certainly the first I've heard of them, and something
>> that must be shared by any other existing implementation of the same
>> thing, considering what they have in common.
>
> Why can't each stream have its own [acm]time and permissions?

Why can't each ACL entry have its own [acm]time as well?
Why can't each hard link to a file have its own [acm]time and permissions?
Why can't each segment of an executable ... ?
Why can't each "char" of a regular file ... ?

No, no, no. This is just silly. Multi-streamed files are just that,
and so the obvious and COMMONLY USED definition involves shared inodes.

> They are largely independent. There are three things (under NTFS) which
> link streams to each other: the first part of the filename, the shared
> [acm]time, and the shared ACL.

The WHOLE name is shared; the foo:bar notation is a shell convention.
Streams also share st_nlink (the hard link count).

Note that directories may have additional streams!!!! These extra
streams are chunks of data, not hidden directories.

There are two existing UNIX-friendly APIs for multi-stream files:

SGI's Irix can do streams with XFS and an extended NFS.
SGI has a Linux kernel that has the required system calls.

Apple's MacOS X, with BSD core, must have an API too. (what?)

For maximum compatibility, Linux ought to support both APIs.
The fd_open() idea Linus had was quite nice too, especially if
it let you do cool stuff like ".." on regular files.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo _at_ vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/