>Why is this beginning to remind me of EA's under OS/2?
>
>If I recall correctly (And it's been one heck of a long time) you could
>bind generic, unspecified metadata to a file, such as the image thumbnail,
>and it would be stored in the EA area.
Yup. Good old Extended Attributes. (I worked for IBM doing install
software for OS/2 for two years. Then I left.)
It's also similar to the macintosh's two "forks", the "data fork" and
the "fork that gets lost when you copy files on a PC". There was a
similar problem with OS/2 EAs getting lost when files were copied under
dos, actually. And the EAs confused some install tools' space
estimation algorithms, which rounded to cluster size and everything but
didn't take the EAs into account...
But the real problem wasn't conceptual. (info-zip for OS/2 supported
EAs just fine, for example.) The problem was the implementation. The
HPFS filesystem could only store 64k of EA data per file, which can get
a bit limiting. The FAT filesystem could only store a total of 64k of
EA data per FILESYSTEM, which was insanely limiting.
EAs turn out to be useful when you're dealing with desktops. Attaching
icons to files is the classic example (you can also do this by
extensions, and Microsoft probably does the same thing via the
registry). Putting information like this inside the file itself
requires the file's data format know about it. Fine for ELF
executables, darn inconvenient for ascii text files, word documents,
etc.
Another use of EAs under OS/2's Workplace Shell was assigning a type to
a file (rather than the default behavior of examining the extension) so
the desktop knows what code to call when you manipulate the icon for
it. (Double click, right click, copy, drag, etc.) ObjType=classname,
if I remember correctly...
And attaching EAs to directories is another way of creating "shadows"
(sort of like a symlink, without the symlink, and more like a hard link
in keeping track of the sucker if it moves, except it can span
filesystems. They did it by black magic and sacrificing live chickens,
hooks in the filesystem that notified the desktop, slowed everything
down. (This wasn't the reason delete was so slow under OS/2, of
course. That was a semi-serious bug in the undelete hash table (code
which ran even when undelete was disabled) which they never fixed
because the developer doing it left and nobody else understood the code,
and IBM wasn't going to spend the resources to fix this (or re-implement
a 32-bit version of the HPFS filesystem when they already had one,
although the HPFS386 code belonged to microsoft and was punitively
licensed...) Never let the bureaucrats near the engineers. It's a
matter-antimatter reaction thingy. Bad things happen to all concerned.)
P.S. I thought somebody proposed an EA-like mechanism for Linux
filesystems months ago. Seeking to negative locations to store data or
something odd like that? (OS/2 did everything with EAs by keyword/value
pairs, which made it hard to screw up the EA data basically by making it
hard to manipulate the EA data -AT ALL-. One way of doing it, I
suppose. "Security by making that feature no fun at all to use". Could
just be their API was very poorly documented and not intentionally
evil...)
EAs are a can of worms I'm not sure we'd want to open. They can be a
useful tool, but there's a fairly high price attached in terms of
complexity. (And they bust the unix metaphor of "cat file | blah >
thingy"...)
Rob
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:26 EST