Do we need to solve this problem quickly, or is a two year time frame fine?
I don't think we need to solve the problem at all. See my previous
message to linux-kernel about why resource forks really don't buy you
much. They end up being too transparent to programs like, cp, mv, and
tar.
Instead, we're much better off designing a high-level API (implemented
using a replaceable shared library) for storing and retrieving metadata
information (and a common metadata format which both KDE and GNOME
share!!!), and then having a shared library which implements the storage
of said metadata information via some non-kernel, non-FS means. If
later somoene wants to extend the filesystem to provide storing resource
forks, fine we can replace the shared library with one that makes the
non-standard, non-POSIX API calls, but I really don't see any value in
storing such information in this fashion over any one of the myriad of
schemes which don't require filesystem support.
Can we tell the NFS standards body that in two years we want to
support files that are also directories, and ask them to join us in
support for it in two years?
The reality is that it will take a lot longer than two years to get any
kind of enhanced NFS support out to end-users. The vendor pipeline is
long, and it will take a long time for people to upgrade their machines
and their operating systems. That's one of many reasons why I don't
think we should even pursue direct filesystem support for metadata
storage.
Do it as in the high-level interface, where it belongs.
- Ted
-
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.altern.org/andrebalsa/doc/lkml-faq.html