[openbeos] Re: kernel mime_table module
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Sun, 09 Jan 2005 16:55:48 +0100
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
Other related posts:
