FreeLists / openbeos / [openbeos] Re: kernel mime_table module

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > > No, it can't, since you generally can't get the name of a node.
> > Also keep in mind BNode stuff might get used without a valid
> > BApplication/BRoster.
> Our be_roster is initialized at libbe initialization time. All 
> registrar 
> services (MIME types, clipboard, message runners, etc.) are available 
> without a BApplication.

Oh, that's great!

> > Trackers sniffs files when:
> > - you right-click them and select the "Open With" submenu,
> > - you dbl click
> > - you start moving the selection
> > - you use "Identify".
> > 
> > The problem currently, and you can see it even on BFS sometimes,
> > is it asks the roster to sniff the file, then reads the BEOS:TYPE
> > attribute.
> > But with RO fs that won't work, and sometimes even on BFS the 
> > roster is
> > too late in writing the attribute, and Tracker tells you "Unable to
> > find an app...", even though you see the icon changed and the file 
> > has
> > been sniffed. Actually dbl-clicking it the next time will bring the
> > correct app.
> Weird. One would think the Tracker uses the `synchronous' flag of 
> update_mime_info(). Anyway, as you say, for RO FSs there must be 
> another 

Wherever the bug is, this doesn't seem to be Tracker's fault; at least 
it really calls update_mime_info() in synchronous mode, I just checked 
it.

> solution anyway (same for FSs that don't support MIME types/
> attributes). In 
> those cases the Tracker can just use BMimeType::GuessMimeType() 
> directly.

But there as well, it would be great if the icon for the file is 
already correct - and I would still assume that a full lookup is to 
expensive there.

> > > > After R1, I want to introduce file system layers, so that we 
> > > > can
> > > > just plug in generic attribute support for all file systems 
> > > > that don't
> > > > support them natively. That should also simplify a couple of 
> > > > things
> > > > :)
> > /me pets union-mount

Dunno, haven't seen it in action yet :)

> > Now, about FAT: OS/2 and Cygwin use a file named EA DATA.SF to 
> > store
> > extended atributes, probably we could use such a file as well.
> > http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html
> If there's a interoperable way to use it, this is certainly a good 
> idea.

http://www.tavi.co.uk/os2pages/eadata.html
From what I found an EA data entry comes with a name and a data field 
which can be arbitrary data. Looks like we could use it. Another use of 
these attributes is for standard POSIX permission sets (that's what 
Cygwin is using it for).

Bye,
   Axel.