# 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.
Just when you thought the 640k limit was poor when the PC was born (to be
honest, I can't say I blame them for that one, considering how things were
back then)...64k per *filesystem*? yuck.
# 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).
Kinda. Shortcuts and executables have the icons stored directly inside
them (shortcuts have them as part of the format, executables have
resource sections, just as OS/2 EXEs could..). The registry keeps track of
which executable or icon file a particular type of file should use to get
it's icon from. The there's the magic icon handlers which are basically
COM servers which are queried to with the path of the filename and return
the icon that Windows should use (i.e., for storing per-file icons in a
custom file format).
The weak links there are:
- If the registry dies, you loose the associations
- There's no easy way to associate a particular icon with a particular
file, without creating a shortcut (which is horribly kludgy, and what
happens if you try to change the icon of a straight 'MZ' DOS EXE).
Being able to store metadata for a file is nice in that you can say "file1
has *this* icon, while file2 has *this* icon", and fall back to the
default icon for the file type if the metadata's there. With this kind of
metadata, you wouldn't expect (and probably wouldn't want) redirection and
piping to carry it across - only full-file copies/moves. Having metadata
carried across in redirection and pipes would lead to all sorts of
not-too-well defined rules that people would never be 100% sure of.
# 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"...)
Well...no, the unix metaphor of "cat file | blah > thingy" breaks
EAs... :)
You have to consider what applications they'd be used for. Quite simply,
you wouldn't use them for anything where the loss would cause more than a
minor niggle to the user. i.e., storing a custom icon. If the user does
<that> and the icon is lost, then the user will know that doing <that>
causes the icon to vanish, and would probably re-set it without too much
thought (of course, if <that> is something they do often, they probably
wouldn't use the custom icons). If the metadata is the result of several
hours' work, then they're going to be mightily pissed if it vanishes
without warning - so quite simply, never store anything non-trivial in
there.
As a slightly related topic, I've been working on a filesystem design
which does full structured storage (i.e., the only differences between a
directory and a file are the attributes). Has anybody been playing with
anything similar? I was going to start work on a VFS module for it, but if
someone's already got one in-progress, I can ditch my efforts and maybe
contribute there instead... (e-mail me privately about this, as it veers
OT somewhat).
-- Mo McKinlay Chief Software Architect inter/open Labs ------------------------------------------------------------------------- GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay <mmckinlay@gnu.org>- 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:27 EST