Messages in this thread | | | Date | Sat, 12 Aug 2000 01:44:28 -0400 | From | Rob Landley <> | Subject | Re: NTFS-like streams? |
| |
>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/
| |