lkml.org 
[lkml]   [2000]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: abstract file (support multi-part)
Date
James Sutherland writes:
> On Sun, 20 Aug 2000, Albert D. Cahalan wrote:
>> James Sutherland writes:
>>> On Sun, 20 Aug 2000, Mo McKinlay wrote:

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

The MFT record is no more or less exposed than an ext2 inode.
I certainly consider an inode to be part of a file.

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

The newer filesystems simply let you have multiple blocks of data.

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

Ah, but they are differently named! No, really, it would be easy
to have different permissions for different links. This restriction
is no more or less sane than having multiple streams share ACLs.

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

Yep, it would be silly, but not (much) more silly than having
per-stream ACLs. Users set permission on the whole 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.
>
> 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.

It isn't much of a weakness if any, and it isn't just an NT issue.
MacOS (with unlimited named streams now), OS/2, and Irix all share
this notion of streams that share security data and time stamps.
Filesystems: NTFS, HPFS, HFS+, XFS, NFSv4, and extended NFSv3.
Most likely UDF has the same design.

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

Hey, I could write a UNIX shell that used foo:bar syntax to access
individual lines of text. (like foo:42 for line 42) That doesn't
make ":42" be part of the filename.

Better yet, I could make a shell that did this:

foo:DATA The file body.
foo:SEC Owner, group, permissions...
foo:TIME The time stamps.
foo:MAP Map of the physical disk blocks in use.
foo:CORE Bit map of blocks currently in core.

It is just a silly shell hack, same as the NT shell uses.
There is only one real filename.

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

Um, you do recognize that, don't you? ("man 2 stat")

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

I could have:

1. directory "f" with file "bar" and extra stream "bar"
2. directory "f:bar" (a 5-character Unicode name)
3. drive "f:" with "bar" in it's current directory

So now "f\bar" is the file and "f:bar" is whatever the
shell and Win32 subsystem give priority to. Three choices!
There might be a way to escape some of these.

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

Go ask SGI. Well, too late now.

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

Oh yeah, I forgot about "chmod 666 /dev/*".

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

HFS+ supports an unlimited number of named forks, like NTFS does.
The whole world is adding this feature.

>> For maximum compatibility, Linux ought to support both APIs.
>
> Do it userside. Avoid kernel bloat.

It is less bloat to just add the damn feature. Without it, we get
crap like our current HFS driver. Ugh!

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

I guess you're sending Linus with me, because Linux used to have
this very feature. Linus was forced to kill it because, being
exposed as "/etc/passwd/../../dev/hda7" it broke old software.
With the fd_open() API, nothing old gets broken. Given only a fd,
you could create a backup file in the same directory.
-
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/

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