On Sat, 12 Aug 2000, Bill Huey wrote:
>> On Sat, Aug 12, 2000 at 04:30:56PM -0400, Theodore Y. Ts'o wrote:
>> > Hence, for many of these filesystems that support extended attributes.
>> > Using the "fd = sub_open", followed by read/write/lseek calls simply
>> > doesn't map well to what they need at all. So instead, SGI Irix's
>> > extend attribute interface looks like this:
>> >
>> > int attr_{get,set}(const char *path, const char *attrname,
>> > char *attrvalue, int *valuelength, int flags);
>>
>> The XFS linux kernel from oss.sgi.com actually already uses that interface
>> on Linux (using system call numbers that have now been taken over by
>> getdents64 et.al., oh well..)
>>
>> -Andi
>
>BeOS uses almost an almost identical set of functions with command line utilities
>supporting explicit modifications of these per-file properties.
>
>It's great stuff since can tag a file by some kind of property, such as a miniturized
>icons, etc... and have be be explicitly be associate with the files instead of having
>that stuff maintained in a database of some sort creating maintenance issues.
The only difficulty I have seen with this is that the Icon (or whatever) has
to stored multiple times, once for each file. If the thumnail is only 256 bytes
its not a big problem. If it gets to be 32K/64K... (ie a stream that is a
program to do something with the file) then it gets bad. really bad. (consider
having to update all the files that might do that...). A better example would
be things like audio annotation attached to a data file.
-- ------------------------------------------------------------------------- Jesse I Pollard, II Email: pollard@cats-chateau.netAny opinions expressed are solely my own.
- 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:28 EST