> > fs_write_attribute_etc("BEOS:CONTENT", "haiku", B_APPEND_TO_INDEX); > > fs_write_attribute_etc("BEOS:CONTENT", "rox", B_APPEND_TO_INDEX); > > fs_write_attribute_etc("BEOS:CONTENT", "windows", > > B_APPEND_TO_INDEX); > > fs_write_attribute_etc("BEOS:CONTENT", "sux", B_APPEND_TO_INDEX); > > > > Of course this would require many ops but would work. > > Would also need some way to clean up all the values for this file > > before reindexing. > > That's interesting because this looks like a very simple extension. > > Question: Does an index with loads and loads of data in it slow down > other indexes in any way? I would hope not. not necessarily, IIRC the BEOS:TYPE attribute is traditionnally not indexed in BeOS because it would be slow, but due to many identical values. > Clearing the index would happen by not using the append flag on the > first value when reindexing, right? Or with NULL or something else... Actually it could also just be an index property instead. One would create the BEOS:CONTENT index with a "keep" flag telling it to retain files unless an empty content is written to the attribute. > I guess only one of the values would show in Tracker, though, which > means it will probably not work so well for other multi-value > examples > that have been brought up before, like setting multiple labels on a > file. Those might require the type to be something like vector of > strings, which is a much more complex extension. Well since it's supposed to be used for full content indexing it wouldn't be interesting to have it shown. There is no reason to have Tracker show it. Just like it doesn't show other attributes it doesn't know about like StyledEdit text_runs or Pe settings. François.