Re: abstract file (support multi-part)

[James Sutherland <jas88 _at_ cam.ac.uk>]

On Sun, 20 Aug 2000, Albert D. Cahalan wrote:
> 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.

Damn. A filesystem is supposed to be a way of storing blocks of data by
name - details like MFT records should be purely internal.

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

We're tracking the block of data, not some internal datastructure of the
FS.

> Why can't each hard link to a file have its own [acm]time and permissions?

Each hardlink refers to the same block of data. Timestamps and permissions
refer to that block of data.

> Why can't each segment of an executable ... ?

Each segment of an executable is just part of the block of data. We
operate on a file (as in "block of data") granularity.

> Why can't each "char" of a regular file ... ?

We don't subdivide these named blocks of data.

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

Eurgh. Our resident NTFS expert mentioned this specifically as being a
WEAKNESS in NT's implementation. I would like to think we can learn from
these mistakes, rather than blindly copying them - even if NT IS obvious
and commonly used.

> > 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).

"Whole name" in this context being "the name up to the :"? Strange
definition of "whole" - it could be interesting to see you testify in
court, telling the "whole" truth :-)

Also, where in an MFT record does this "st_nlink" thing live?

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

Hrm. A chunk of data, in a directory, with a name. We've met those things
before, somewhere...

> There are two existing UNIX-friendly APIs for multi-stream files:
> 
> SGI's Irix can do streams with XFS and an extended NFS.

Eurgh. Why break NFS unnecessarily to add this "feature"?

> SGI has a Linux kernel that has the required system calls.

Eurgh. Do it userside: the kernel provides enough of an API to do it.

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

If you're meaning HFS's resource and data forks, that's another matter
entirely.

> For maximum compatibility, Linux ought to support both APIs.

Do it userside. Avoid kernel bloat.

> The fd_open() idea Linus had was quite nice too, especially if it let
> you do cool stuff like ".." on regular files.

Oh fsck. You want to put "cool stuff like '..'" into regular files? Move
to Redmond.


James.

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