[openbeos] Re: kernel mime_table module
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Thu, 06 Jan 2005 15:53:52 +0100
On 2005-01-06 at 07:02:58 [+0100], François Revol wrote:
> >
> > > I would chose BNodeInfo as a starting point, as this class is the
> > > one
> > > that abstracts the file type stuff from the implementation.
> >
> > Well, the `abstraction' is very direct. The properties it can get/set
> > are
> > directly stored as is in the node's attributes. There's little magic
> > here.
> >
> > > Whenever a file does not have the BEOS:TYPE attribute set (for
> > > whatever
> > > reason), it could get the type via the file extension only.
> >
> > 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.
> > > I am not sure when Tracker does this; I would guess that it only
> > > loads
> > > additional attributes on demand, but not determine the file type
> > > this
> > > way.
> >
> > Yes, you're right. Looks like the MIME type is obtained when opening
> > the
> > Model. But I suppose it shouldn't be impossible to change it to
> > initialize
> > it to the generic file type for FSs that don't support attributes/
> > MIME
> > types and fix it later when needed or in the background.
>
> 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
solution anyway (same for FSs that don't support MIME types/attributes). In
those cases the Tracker can just use BMimeType::GuessMimeType() directly.
> > > 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
>
> 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.
> I think NFSv4 has a form of attribute support as well, didn't dig in
> yet, as we only support v2 for now.
Dito.
CU, Ingo
Other related posts:
