I'm not sure why you reacted so violently to my posting. I also have no
idea what you are talking about when you say that my proposals
necessarily means "Structured Storage", or exactly what you mean by
that, and why it is such a horrible thing. If you could define
"Structured Storage" and then give a quick run down about why it's so
horrible, that would be helpful. I certainly wasn't suggesting that
glibc would be taking on the role of namei(), so I think there is some
massive confusion going on here.
My arguments for not wanting to do multiple-fork files have nothing to
do with whether or not any specific filesystem --- reserifs or ext2fs
--- could be able to support multiple-fork files, efficiently or
not-so-efficiently.
Let me run them down again. Point the first, KDE at least doesn't want
to be tied down to Linux. They want a general solution that works well
on all operating systems. So a Linux-specific approach using filesystem
hacks doesn't work well with their desires. I assume GNOME has similar
requirements about not wanting to tie their desktop to only working on
Linux. Most Unix systems don't support multiple data streams in a
file, and using such features inherently makes their systems
non-portable.
Point the second, given that the utility programs --- cp, tar, etc. ---
don't know about this non-standard resource forks, they won't be able to
properly copy these files, causing all sorts of confusion. Yes, we
could modify them to know how to copy the metafile information, but in
that case what's the advantage of storing the a resource fork? You
might as well store it in a separate file, since you'll have to modify
the user-mode code anyway.
Point the third, if critical application-specific information is stored
in the resource forks, standard Internet protocols such as ftp and http
won't be able to deal with files with multiple data streams.
Note that these objections to using filesystem hacks to support meta
filedata have nothing whatsoever to do with filesystem design
arguments. They are all about how you would actually use such new
filesystem features.
As I mentioned before, NTFS has support for multiple data streams.
According to a Microsoft developer, they aren't planning on using this
feature for much, precisely because of these concerns, which are really
external to the whole filesystem design question.
- 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