Linux-kernel mailing list archive 1999-25,: Re: File systems are semantically impoverished compared to

# Re: File systems are semantically impoverished compared to

Albert D. Cahalan (acahalan@cs.uml.edu)
Fri, 25 Jun 1999 21:55:31 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Linus Torvalds: "Re: [RFC] File flags handling - proposal for API."
- Previous message: Albert D. Cahalan: "Re: (reiserfs) Re: File systems are semantically impoverished compared to database"
- In reply to: Khimenko Victor: "Re: File systems are semantically impoverished compared to"

Khimenko Victor writes:
> In <Pine.GSO.4.10.9906250430410.24019-100000@weyl.math.psu.edu> Alexander Viro (viro@math.psu.edu) wrote:
>> On Fri, 25 Jun 1999, Albert D. Cahalan wrote:

> But I'm not so sure that we need support for such beast in kernel.
> IMO better to implement userspace library with albod support and
> then [if all will work as desired] pull some time-critical parts
> in kernel.

The userspace version already exists. It is called a compound document
file or structured storage. Users with large image-laden documents
tend to have performance problems. Users are forced to work around
the problem. (by putting each chapter of a book in a separate file)

See my response to Theodore Y. Ts'o for why this is broken.

> I seen few messages with compains against such way: `One must be
> able to "rm" or "mv" the whole document with any old tool. That
> really ought to include old statically linked tools. ... I'll
> expect to _not_ see "magic" file names in directories. I'll also
> expect something that the NTFS driver can use.' but I'm noot seen
> rationales under such complains.
>
> Why it "really ought to include old statically linked tools" ?
> Do you really have that many and why you can not recompile them ?

Some people still use libc 4. Some people have commercial software.
Some people have lost their source code.

Userspace should not suddenly break.

> Why you expect to _not_ see "magic" file names in directories ?

That was the only thing they could do from userspace, and it stinks.
It is a slow and unreliable way to identify a compound document.

> And you'll see "magic" names related to albod handling only when
> compatibility libraries are noty preloaded anyway.

So, what happens if the hidden name is ".albod" and my software
tries to use ".albod" as the name of a document component?

> And why expect something brain-dead enough to support "MS way" on NTFS ?

Sorry, but Microsoft isn't going to just go away any time soon.
Most of the world has to deal with Windows tools, Windows clients,
and Windows filesystems. It will take a _minimum_ of 20 years for
the world to get rid of Microsoft.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Linus Torvalds: "Re: [RFC] File flags handling - proposal for API."
- Previous message: Albert D. Cahalan: "Re: (reiserfs) Re: File systems are semantically impoverished compared to database"
- In reply to: Khimenko Victor: "Re: File systems are semantically impoverished compared to"