Sure. But in that case, exactly what are you going to be storing in the
metadata? It has to be information which is can be rederived from the
main data fork. But in that case, why not just use the information from
the main data fork and be done with it?
My point was precisely this --- if you restrict yourself to data for
which it is harmless if the metadata disappears, then there generally
isn't very useful for the application. There might be a few specialized
uses for it, but is it really worth all of this effort for a rather
marginalized uses?
For the desktop, if you want to store information about where on the
screen the icon should live, then perhaps that would be a valid use of
metadata --- but that's a desktop use, not an application use.
But as Alan Cox has pointed out, information about what icon to use, and
where on the desktop the icon should live, or even which application to
use when opening a file (emacs or vi?!?), etc. really should be stored
on a per-user basis. Furthermore, the user should be able to modify or
store this information for files for which the user doesn't have write
access. You also don't want to have different users being able to
modify this information for other users. All of this means that it's
probably best to store all of this information in a central database or
dotfile in the user's home directory.
So it's not clear that file metadata would be useful for desktop
systems, either!
This brings me back to my first observation --- it's not at all clear
how useful file metadata really is. Could one of the advocates of file
metadata give me an actual proposed application which could profitably
use it?
- 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.tux.org/lkml/faq.html