Messages in this thread | | | From | "Albert D. Cahalan" <> | Subject | Re: File systems are semantically impoverished compared to | Date | Fri, 25 Jun 1999 21:55:31 -0400 (EDT) |
| |
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)
From userspace, you only get the performance by using directories. 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/
| |