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

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On 2005-01-09 at 16:33:35 [+0100], François Revol wrote:
> > > > 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.
> > 
> > The kernel can do this, or at least it could do this if we need to.
> In fact, all it would need to is keep the dev/ino of the parent folder
> of opened files, and make sure it's up to date (from notify_listener).
> That way one can construct the path on request.

Mmh, interesting idea. You would need to store (and update) the entry name 
itself as well, though, since there may be more than one entry in the 
directory referring to the file in question.

> I fact I want to add that to Zeta to get something like lsof, which is
> sometimes very useful :)
> Now, having that in the kernel-side of the fd will account for fs which
> support hardlinks, while having that in the vnode itself can leed to
> races if the node is open from 2 different paths.
> (not supporting hardlinks in BFS doesn't mean we can't support them at
> all, in fact *bfs* doesn't support hardlinks only because it has to
> support queries)

Why should the query support affect the ability to support hard links? IIRC 
AGMS's RAM FS supports both.

CU, Ingo