The main alternative to storing icon information, file type information,
etc. in a "resource fork" is to store this information in a separate
database file. For the sake of argument, let us suppose that the
desktop system were to use a per-filesystem db/dbm file to store this
information.
The traditional argument against such an approach is that it doesn't
handle the case of what happens if people copy the file using some
access path which doesn't involve the desktop system. Say, the user
types /bin/cp or /bin/mv in a shell window, and suddenly the central
database file is now out of date.
However, what people forget is that even if we store the file
type/class/icon information in a "resource fork", traditional
applications which assume a POSIX-only system API (like /bin/cp,
/bin/mv, etc.) won't know to copy the resource fork! Hence, there
really is no advantage to storing the file metadata in the same location
as the file!
You could modify the /bin/cp, /bin/mv, /bin/tar, /usr/bin/emacs, etc. to
understand about the non-standard, non-POSIX interface used to access
the resource fork --- assuming you could get them all --- but in that
case, you might as well modify all of those programs to modify the
centralized database storing the metafile database instead.
In fact, probably the right thing to do is to solve this problem at the
API level. Define an interface which given a filename, either extracts
or stores the Meta File information for a particular file. Let that
interface be accessible via a shared library, which can be replaced as
necessary. We will need this interface regardless of whether the Meta
File information is stored alongside the file, using a non-POSIX
resource fork, or in a per-filesystem database file. All we need to do
is replace the shared library as necessary to accomodate different ways
of storing the meta file information.
- 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