> I see a problem here that has not been addressed by either a
> filesystem-level or non-filesystem-level solution.
>
> In most circumstances you could divide non-albod-aware programs into two
> classes:
>
> 1) Those that should get a single-stream representation of the albod
> when they open it.
> 2) Those that should just get the default stream.
>
> However in a lot of cases it is not at all clear which
> of the above is appropriate.
What we need is a way to have _both_ possibilities. Even a
(gross) hack to do both is better than to run into the problem
you paint above.
Maybe we want to just list "file" as a standard file with the
dir listing but be able to open "\file" as an albod directory
when we ask for it. Most (almost all) non-albod-aware programs
have the possibility of explicitly entering a file/dir name to
perform an action on so it will just be a minor inconvenience
while some system tools will be converted.
Besides, when you use file/logo.gif the system doesn't have
to guess what you want to do so it'll be not that much of a
problem once we've got a method in place of accessing an albod
in both ways.
cheers,
Rik -- Open Source: you deserve to be in control of your data.
+-------------------------------------------------------------------+
| Le Reseau netwerksystemen BV: http://www.reseau.nl/ |
| Linux Memory Management site: http://www.linux.eu.org/Linux-MM/ |
| Nederlandse Linux documentatie: http://www.nl.linux.org/ |
+-------------------------------------------------------------------+
-
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/