> On Fri, 25 Jun 1999, Albert D. Cahalan wrote:
>> For now, every app with this problem has to implement something like
>> a growable (and hopefully shrinkable) filesystem within a file.
>> Apps can add a block mapping layer complete with triple-indirect
>> blocks, or they can copy around huge amounts of data and update
>> document references as needed.
> The point being that they *do* that. Each has its own bloody format. Each
> will *have* to carry that code around, unless you will manage to push
> every blasted thing into the kernels. Yup, plural. Linux is not the only
> UNIX.
Take look on [almost] ANY program which works under few *nix'es. You'll find
that there are A LOT OF #define's anyway. So if there will be some "growable
(and shrinkable) filesystem in file", used on legacy *nix'es and [much smaller]
code to use file-forks (or albods, of whatever) on Linux plus some additional
code to convert between three formats on Linux it will not expand program too
much (you need convertor from legacy format on Linux and from
file-autocreated-from-albod on legacy *nix'es): even if file formats are not
trivial most code still used not to handle file format. What the benefits then
if code to read legacy format will still be there ? Answer is simple: it will
be there. On disk. Not in memory [in most cases]. Are you tried to work with
16-20-30Mb documents/spreadshits with a lot of pictures and such ? Painfully
slow is the only word to describe process :-((
> Good luck doing that. If you are going to invent a new uniform
> scheme - fine, go ahead, implement it as filesystem and I will write a
> loopback-mount-on-the-fly.
Hmm. What about changes in sizes ?
> Oh, and don't forget to make them switch to new format. Deal?
Hmm. Chicken-egg problem: programs can not switch to new format since we do
not have support for this format and we do not need new format since there are
no applications with it's usage. Right ? No. There are no such application and
may be ven if support will be ready aplication developers will not use it but
at least if there are no support aplication developers can not use it.
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.
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 ?
Why you expect to _not_ see "magic" file names in directories ? Take look on
KDE/GNOME/whatever: there are ALREADY quite a few "magic" file names :-((
And you'll see "magic" names related to albod handling only when compatibility
libraries are noty preloaded anyway.
And why expect something brain-dead enough to support "MS way" on NTFS ?
-
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/