Messages in this thread | | | From | Jesse Pollard <> | Subject | Re: NTFS-like streams? | Date | Sat, 12 Aug 2000 18:29:33 -0500 |
| |
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.net
Any 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/
| |