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