Messages in this thread |  | | Date | Sun, 20 Aug 2000 21:57:55 +0100 (BST) | From | James Sutherland <> | Subject | Re: abstract file (support multi-part) |
| |
On Sun, 20 Aug 2000, Albert D. Cahalan wrote: > James Sutherland writes: > > On Sun, 20 Aug 2000, Mo McKinlay wrote: > >> Today, James Sutherland <jas88@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@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |